[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:       nicolas.brodu () free ! fr
Date:       2000-05-15 11:54:46
[Download RAW message or body]

Quoting Stefan Westerfeld <stefan@space.twc.de>:

> > 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.

I didn't try, but I can see no reason why it wouldn't work. In fact, DynamicCast
is just a class like Reference and SubClass, with the difference that its
constructor is explicit (so conversion from object is refused at compile time if
you don't cast it). In the inherited object code, the constructor from
DynamicCast calls the internal _cast function, so that's why I see no reason why
it wouldn't work on all objects (local or remote).

> What is the advantage of this code right now against virtual ports? I've

None technically, and it actually more limited. You complained about how ugly it
looks in the TODO, so I just propose an easy way/syntax to do it. I think, if
you like this syntax as well, the best thing to do would be to merge them as you
propose (base the aliasing code on the _virtualize functions). In any case, I
still don't understand exactly how this virtualize stuff works!

> 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.

No, my simple code cannot. The aliases are just redirections to the real ports,
so if you change the group the old connection would still remain. It cannot do
transport either.

> Maybe aliasing should base on _node->virtualize?

I totally agree. See above.

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

Perhaps, I don't know. Probaly yes...

> 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.

That would be really great, the ability to define classes at run time! But looks
quite complicated to me (I hope it does not to you, though :-))

Cheers,
Nicolas
_______________________________________________
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]