[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 17:29:35
[Download RAW message or body]

   Hi!

On Mon, May 15, 2000 at 01:54:46PM +0200, nicolas.brodu@free.fr wrote:
> 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).

The problem is that in line 1, only an A_stub gets created. The _cast method
of that A_stub can of course only cast to A_stub and Object_stub, because the
A_stub is no B_stub.

So in line 3, the cast of the stub object fails, and bb.isNull() is true.

There are two ways of fixing this: in line 1, you could make MCOP instead
create the highest known stub (note that "global:SomeB" might really be
a C object for which no stub exists in the calling process).

The other is: in line 3, if _cast fails, you could convert the object once
to a string, and then back to a real B object, which creates another stub.
However, there would need to be some type checking, so that you can't cast
to anything you like (i.e. isNull() gets correct). Currently, you can
convert an X to a string, and to an Y, although X and Y have no inheritance
relation (which should probably be fixed anyway).


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

I've added a fairly complete description how the algorithm works into
virtualports.cc now.

> [...]
>
> > 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 :-))

It is a bit complicated. What we need is a way to implement objects without
really knowing the interface before. In CORBA, this is known as dynamic
skeleton interface.

However, making it appear as if it were a real C++ class should work the
same way _stub's do. They catch the invocations through the virtual methods
and transform them into something generic interface, that is the same for
all objects.

In the case of _stubs, this is MCOP messages. There are two ways, either
make a third branch of _base-inherited objects (like having Foo_dynamic,
Foo_stub and Foo_skel for every Foo interface), or integrate the code
somehow with the _stub code.

The difference between proper virtualization and what we have right now are
for instance attributes, too - you can't virtualize attributes right now.

   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]