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

List:       kde-multimedia
Subject:    MCOP interface versioning
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2000-11-19 15:29:23
[Download RAW message or body]

   Hi!

It has come to the point at last, where we'll need to keep binary
compatibility but want to add features nevertheless. As changing
existent interfaces is binary incompatible due to C++ virtual functions,

Here are my current thoughts about how we could do this. It's not pretty,
but we'll need to do something or we won't be able to extend anything at
all.

So suppose you want to extend

module Arts {

interface InterfaceRepo {
	long insertModule(ModuleDef newModule);
	void removeModule(long moduleID);
	[...]
};

};

I want to do this, that's why I am taking this as example. As it is not
possible to do this by adding methods without breaking BC, I suggest
the following standard way to do it: inherit, and reimplement things.

module Arts {

interface InterfaceRepoV2 : InterfaceRepo {
	/*
	 * the new function, finally
	 */
	TypeIdentification identifyType(string name);
};

};

If we do a release, of course, this new interface will be frozen, too, and
the next extensions will go into V3, V4, V5, ... until we can at last merge
them all again, when we make a binary incompatible release (i.e. KDE3).

As some functions will still return old InterfaceRepo references, and that
can't be changed due to backward compatibility, either, you'll need to
use DynamicCast to access the new functions, i.e.

	Arts::InterfaceRepoV2 ir2
		= Arts::DynamicCast(Dispatcher::the()->interfaceRepo());
		                 // ^^^ returns the normal version ^^^

Of course, if you do this with objects that don't have a new implementation
this will return null. I am afraid there is not much we can do about that.

Maybe, if we standarize on that way, we'll need to extend the ObjectManager,
too so that if somebody requests an Arts::Foo object, it will prefer to
return an Arts::FooV2 object instead if there is one, or an Arts::FooV3,...

That way, for instance if we had an extended StereoEffectStack object, the
apps that create a StereoEffectStack (like artsd) would automatically use
the new version when available.

A final remark: of course, changing an interface which lots of other objects
implement (like Arts::StereoEffect or even worse, Arts::SynthModule) is
probably a very very very bad idea, as all these objects will have to be
rewritten, so this shouldn't be done unless it is completely unavoidable.

Any comments?

   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]