Question about the interface classes

[Matthias Kretz]

On Friday 22 June 2007, Håvard Wall wrote:
> > - less/no multiple inheritance for backend classes
>
> Why is that? Currently you need to subclass both the interface classes and
> QObject. You could make the current interface classes inherit QObject, add
> the virtual functions, make dummy implementations. Wouldn't that be easier
> for everybody. Anyway, you have much more experience with phonon than me,
> so I'm probably missing something or are just plain stupid -)

Let me check whether the reasons still make sense (after that many API changes 
it might just be that there's currently no problematic case)...

It's still there with Effect and specialized Effect subclasses. Before I was 
in Oslo this problem was a lot more visible with the classes 
AbstractMediaProducer -> MediaObject -> MediaQueue. Anyway this is the 
problem:

let's assume for every frontend class we define a backend interface that 
inherits QObject:
Effect -> EffectInterface
VolumeFaderEffect -> VolumeFaderEffectInterface

a) EffectInterface inherits QObject, VolumeFaderEffectInterface inherits 
QObject
=> obviously doesn't work because a VolumeFaderEffect implementation would 
have to inherit both EffectInterface and VolumeFaderEffectInterface

b) VolumeFaderEffectInterface inherits EffectInterface instead of QObject
=> the backend implementation can inherit VolumeFaderEffectInterface now, but 
it cannot inherit its implementation of Effect anymore since that one 
inherits from EffectInterface.


Therefore, in order to be able to use inheritance in the frontend classes and 
the backend classes the interfaces may not inherit QObject.

This problem can be solved by using Q_INTERFACES, which is a really nice 
solution, that I only learned a few months after I changed everything to use 
invokeMethod. So from there I gradually changed many interfaces to use 
Q_INTERFACES instead - but not all since I thought it doesn't hurt much and 
is even more flexible than Q_INTERFACES.

BTW, there are 39 functions defined that way with ~1173 characters used to 
write out the function signatures. I'm not sure whether this really has a big 
impact on the binary size of the lib or backend.


Have to go now - so I send this mail a bit unfinished...


> > Virtual functions make it harder to keep BC.
>
> Sure, I understand you can't add virtual functions after
> code-freeze/release, so new functionality added at a later stage would have
> to use the
> invokemethod trick.
>
> > For embedded I'd expect the backend to be compiled into libphonon anyway.
> > So there you'd redefine the macros to call the backend functions directly
> > instead of going through the meta object.
>
> This would make supporting new hardware for an embedded device more work.
> The customer doing the integration no longer only have to write a (more or
> less) simple plugin, but also has to change the optimize the phonon
> libraries. I'm afraid that this increased complexity/cost will make it
> harder to convince people to use phonon on embedded.
>
> > My libphonon has 342kB stripped (x86). But like I said, for embedded
> > you'll want to compile the backend into libphonon and make direct
> > calls...
>
> Sure, it's smaller on x86. Doesn't help on ARM though..
>
> Anyway, I get the message..
>
> --
> hw
> _______________________________________________
> Phonon-backends mailing list
> Phonon-backends at kde.org
> https://mail.kde.org/mailman/listinfo/phonon-backends



-- 
________________________________________________________
Matthias Kretz (Germany)                            <><
http://Vir.homelinux.org/
MatthiasKretz at gmx.net, kretz at kde.org,
Matthias.Kretz at urz.uni-heidelberg.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/phonon-backends/attachments/20070622/d9a3329f/attachment-0001.pgp