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

List:       kde-multimedia
Subject:    Re: SynthModule in the idl
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2000-05-16 17:21:14
[Download RAW message or body]

   Hi!

On Tue, May 16, 2000 at 02:57:04PM +0100, Nicolas Brodu wrote:
> 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.

Well, I somewhat had in mind your old implementation which was adding
start() / stop() methods at random, and these only to the SmartWrapper,
but not to the MCOP type system, which would break JavaScript and such.

One thing we could do in any case for newcomers is emitting a warning if
you forget SynthModule inheritance.

The other thing would be making 'mcopidl' perform exactly in the same way
that it would if you wrote ": SynthModule", even in case you forgot it,
without emitting a warning. This would be conforming to the type system,
as the type system would still think the user inherited from SynthModule.
So it eliminates most of my doubts.

SynthModule would stay an IDL interface, as it is now. It would just be
inherited implicitely by streams carrying modules which do not inherit it
explicitely already.

Ok, so would that be your proposal, or do you want to alter the mcopidl
behaviour different (or more) by also generating the code for inheriting
StdSynthModule, and pulling in "stdsynthmodule.h"?

There are a few things that are not nice:
- currently mcop and artsflow are only loosely coupled - you can reimplement
  the whole flow system easily with these changes, this will probably get
  lost
- you'd need to implicitely #include <artsflow.idl>, which could be quite
  tricky (currently the user needs to do this)
- casting to SynthModule will succeed even if there is no reason to (from
  what you'll read in the idl)
- kdoc will mess up the class hierarchy, so SynthModule will not be seen
  in the inheritance hierarchy
- don't fix it if it ain't broken - these things work fine now, there are
  quite some things which are showstoppers which are probably more important
  to work at

Well, if you want it anyway, go for it, but give me the changes for review -
good documented - before committing anything. Please complete the work
on the SmartWrappers and dynamic casting before in any case, as it is probably
easier when we complete one thing after the other, and not everything at the
same time.

   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]