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

List:       kde-multimedia
Subject:    SynthModule in the idl (was: Re: SmartWrappers => Object conversion
From:       Nicolas Brodu <nicolas.brodu () free ! fr>
Date:       2000-05-16 13:57:04
[Download RAW message or body]

Stefan Westerfeld wrote:
> > Of course it should stay... in C++!
> > I mean that for the examples I posted, an interface is written as:
> > interface MyInterface {
> >     out audio stream gargle;
> > };
> > and does not inherit from SynthModule (which is now implicit since I declared a
> > stream).
> > It's just a matter of mcopidl adding a parent (SynthModule) when a stream is
> > detected. The coder doesn't even need to know, as inheriting from the skel
> > doesn't make SynthModule appear. That way, SynthModule is really internal, and
> > the idl looks nicer. The start()/stop() functionality is viewed as something you
> > get automatically when you declare a stream.
> >
> > OK for this change?
> 
> I know that the temptation is big to let mcopidl generate everything sometimes,
> where needed or if the phase of the moon is like this. We can do that, after
> all. However, doing so excessively will make things very hard to understand.

I agree that too much will make it hard to understand, but in that case I think
it would actually make it easier. Or people will complain: "What is a
SynthModule (or another name) for? I've declared a stream, why can't I use it?"
It seems confusing to me that declaring a stream isn't enough in itself. At
present you have to add the dependency to make it work. And that's what I'm
criticizing, the inheritance is redundant.

> I don't want methods popping up and disappearing at random. If they are not
> declared in the interfaces, they are not supposed to be there. If you need
> something sometimes but not always, then inheritance is the way to go.

Well, what about calculateBlock then? We already treat different streams with
different methods popping up. And it will be more so with video. Granted, the
stream is declared in the idl. But what I mean is that when you declare a
stream, you could get start() and stop() the same way as you would get the sream
implementation. Just something that makes it work and you know you will have,
and why it is there.

> How should a JavaScript binding know that there might be a stop() sometimes,
> but not always? How should a user know, who only has read the IDL files (which
> will be the source of documentation via kdoc)?

Because there is a stream. stop() is there iff there is a stream, not 'sometimes
but not always'.
Besides which, if you don't inherit from the SynthModule in the idl, you let the
implementation of idl => other_language_than_C++ free to implement start/stop in
any way.

Now, my whole reasonning collapses down if you want a stream without start/stop.
But that would be pretty useless, wouldn't it?

Regards,
Nicolas
-- 
A shortcut is the longest distance between two points. (unknown author)
_______________________________________________
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]