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

List:       kde-multimedia
Subject:    Re: 'default ' keyword working.
From:       Nicolas Brodu <nicolas.brodu () free ! fr>
Date:       2000-03-21 14:10:12
[Download RAW message or body]

Stefan Westerfeld wrote:

> > The connection asserts that the number of defaults match for the input/output of
> > the connected objects, when the ports aren't specified explicitely. Another
> > possibility would be to do as many connections as possible between the source
> > and destination objects. This would partially solve the inheritance issue above,
> > but then one must be more careful when connecting 2 objects. What do you prefer?
> 
> Is there something that speaks against this behaviour:
> - if you don't mention the keyword default in your object declaration, the
>   default ports are left as they were in the parent object

Except in the case the parents have no default port and the object has only one
=> it becomes the default. But yes, I'll code up this fine behaviour.

> - if you do, the default ports are set to what you say, so you don't honor
>   parents default ports any longer

That would be fine, but you cannot then add a default to the parent ones. Hmm,
we could honor only the default ports specified in the idl as you suggest here,
but in the case a string does not match one of the ports of the object, then
look if it comes from a parent default. This would be even cleaner since it
allows to do exactly what you want in the inherited objects, and keep the
possibility to reuse parent ports!
Is there a simple way to get the parent interfaces in mcopidl (they could come
from an included idl)? If not, I'll do the test at run-time (in the generated
code), after all, default ports are used only during connect so the small
overload won't matter that much.

> I think that might be a clear behaviour. Of course, if you inherit from two
> objects which both have default streams, then you loose - but hey, we can't
> do magic ;)

With the behaviour above, you won't loose ;-)

> 
> > On another topic, I didn't have time to investigate but it seems that the
> > smartwrapper code have a minor reference counting bug somewhere for remote
> > connection. More precisely, artscat ends up after a few seconds when the
> > reference clean finds a not so 'unused' object and frees it.
> 
> I thought a bit about reference stuff (without reading the code too deeply),
> and I see a few issues that smartwrappers maybe don't handle correct yet.
> 
> ==> 1. Returncodes vs. Parameters:
> 
> Object_base *doSomething(Object_base *foo)

Well, I modified the Returncodes & Parameters to use smartwrappers, but since
there is no smartwrapper for Object I kept Object_base* instead. That's the
reason of the inconsistency I think. What changes would be necessary to generate
a smartwrapper for Object? (if needs be, we could call it Object_wrap to keep
the Object class as it is now).

> ==> 2. Null references
> 
> I think there are issues with null references. The current smartwrappers
> often do
> 
>   if(!nullreference) assign(...);
> 
> however, I would be amazed if I do:
> 
> Synth_PLAY p;
> p = remoteObject.doSomething();
> if(p.isNull()) cerr << "no object" << endl;
> 
> and doSomething *really* returns a null reference. What would happen is that
> upon calling p.isNull(), auto-creation kicks in, and you don't get the error
> msg, but a fresh locally created object. Thus, you need to do
>
>   if(nullreference) assign(0);
>   else assign(reference->_copy());
> 
> in all those cases.

The only solution I see now involve spliting internally isNull() into nullity
and error conditions. But then, there is overload because the error flag is
positionned after each method call. Now that I think about it, it would make
code more robust. But is it what we want (is the robustness worth the small
extra overload)? 


> ==> 3. "Fixed" autocreation?
> 
> void calc(Synth_FREQUENCY param)
> {
>     // 2. a copy is made, but left unassigned
>     setFloatValue(&param,440.0);  // 3. the copy gets autocreated here
>     // 4. the copy gets destroyed here
> }
> 
> main()
> {
>     Synth_FREQUENCY f; // 1. f is unassigned (but ready to autocreate) here
>     calc(f);           // 5. f is still unassigned here
>     f.start();         // 6. f is now created, however without 440 Hz setting
> }
> 
> I think this is a new bug in the fixed auto creation. You need to do the
> creation upon copy. (As the program should work exactly the same as if f
> would get created in 1. already).

That's no bug! It's standard C++ issue. void calc(int a) would not modify 'a' in
the caller as well. In this example, void calc(Synth_FREQUENCY& param) is
correct, because you want 'calc' to do something on the main 'f'.

> ==> 4. _vars can also be null references
> 
> Well, that should be clear. Foo_var f; f->_copy() is also fatal. Assignment
> operators and such should check that and do the same as in 2.

Yep, I missed this one! I corrected your operator=(Class_base* target) to test
for the nullity of target, but didn't think about it when introducing an
operator=(Class_var target). Stupid me!


Ah, another long mail...


Cheers,
Nicolas
-- 
A shortcut is the longest distance between two points. (unknown author)

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