[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: More MSOP stuff: dynamic casting and aliasing
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2000-05-15 10:41:52
[Download RAW message or body]

   Hi!

On Sun, May 14, 2000 at 08:44:13PM +0100, Nicolas Brodu wrote:
> I've also written dynamic casting and aliasing this WE. What it is:
> 
> Dynamic casting:
> 
> Suppose you have interface A : B {};
> You can write
>   B b;
>   A a = b;  // True as for standard C++ pointers
> But now if you do
>   Object o = a;
> You know that the object is a B, but cannot assign it to a B variable.
> 
> Now you can, by writing:   B bb = DynamicCast(o);
> 
> If the cast wasn't possible, bb.isNull() will be true.

Does it work even in the remote case? So can I write

A a = Reference("global:SomeB");
Object o = a;
B bb = DynamicCast(o);

It has to, if we offer it.

> Aliasing:
> 
> This is very similar in functionalities to Stefan virtual ports, in the sense
> that it provides masquarading and dynamic composition. Since Stefan complained
> in the TODO about the virtual ports, I felt free to write something different.
> 
> Example: You have some effect filters, and would like to group-chain them and
> treat the result as a single filter object. It is now possible. Supposing all
> Effects have an "input" and an "output" port:
>   Effect e, f, g;
>   connect(e,f);
>   connect(f,g);  // That makes the chain of effect
>   Object group;
>   alias(group,"input",e,"input"); // this create a port name "input" in group
>   alias(group,"gout",g,"output");  // and another named "gout" (for a change)
> Now if you have
>   DataProducer d;
>   Player p;
> You can do
>   connect(d,group,"input");  // In fact connect d to e
>   connect(group,"gout",p); // and g to p
> 
> group has become a single object that calls in fact the 3 others, transparently. 

What is the advantage of this code right now against virtual ports? I've put
quite a bit of effort into virtual ports, and they support for instance things
like changing the structure of the group while it is still connected somewhere
from outside.

Look for instance at StereoEffectStack. It gets connected from outside, so
you'll have

Producer
   |
   V
StereoEffectStack
   |
   V
Consumer

StereoEffectStack at the beginning forwards its inputs -> outputs. When you
insert effects, it passes data through effects instead. You don't need to
reconnect producer/consumer, as their connections will be rerouted by the
aliasing code.

Maybe aliasing should base on _node->virtualize?

Can it do

StereoEffectStack s = ...;
StereoEffect fx;
/* ... define fx somehow through aliasing ... */
s.insertTop(fx);

My plan for the next time would be to provide only the most essential hooks
in MCOP itself, and let artsbuilder then have an ArtsBuilderRuntime module,
which will run inside artsd (or other processes) to allow the creation of
flow graph implemented classes.

For instance, you should be able to write

StereoEffect fx = SubClass("SpecialVerb");

And SpecialVerb should be an artsbuilder created flow graph through aliasing/
virtualization, created through the ArtsBuilderRuntime module.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
_______________________________________________
Kde-multimedia mailing list
Kde-multimedia@master.kde.org
http://master.kde.org/mailman/listinfo/kde-multimedia

[prev in list] [next in list] [prev in thread] [next in thread]