Re: Class Inheritance

[Patrick Lidstone]

> >- What about polymorphism? For example,
> >audio.transport might have the concept of vol=10 on a 0-10 scale
> >whereas the derived class audio.transport.merdian might redefine
the
> >concept of vol to be measured in db).
>
> I suppose in some respects this is implicit in the device. It gets
the
> volume value in its native (base class) scale (0-10), and interprets
> it as it sees fit anyway.
>
> But here I'm thinking that the derived class schema alters the
> formatting/meaning of the value entirely.

Not sure I've understood you PoV here. We cannot allow a derived
class to redefine a base class element, only to extend the class.
Otherwise no device that understands just the base class can make use
of it, because the meaning of a particular value may have changed!

> It seems complex.

Complex is bad :-)

> If I had an app that looked for xAP-Audio.Transport messages, on
> receiving a xAP-Audio.Transport.Meridian, I guess I'd look for
> recognisable xAP-Audio.Transport message blocks, and ignore the
rest,
> assuming they're for the derived class(es).
>
> Thus a xAP-Audio.Transport.Meridian message block would not be valid
> in a xAP message body where the Class was
"xAP-Audio.Transport".
>
> If we have a class such as this:
>
> Class = xAP-Audio.Transport
>
> Audio.Transport
> {
> Command=[play  pause  stop  next  prev]
> --- mandatory
> Param=[on  off]
> --- optional (depending on Command/Hardware support)
> }
>
> And we derive a class:
>
> Class = xAP-Audio.Transport.Meridian
>
> In this, lets just say for sake of example (I don't know if this is
> supported) that the Meridian transport supports a 10s preview of
each
> track before skipping to the next one.
>
> I want to add this new command to the Audio.Transport message block.
> Is that appropriate?
>
> Audio.Transport
> {
> Command=[<Inherited>  scan]
> }
>
> Ie "Scan" is a new command added to the block parameter.

That's all well and good, I think - extension of the enumerated
values is ok.

There's an argument to be made for calling the block
audio.transport.meridian since the base class can be derived
implicitly, and this adds a clear indication of the expected block
content when it is broken apart from the header.

> >- What about multiple inheritance? (Where a new class is derived
by
> >combining two base classes, not simply by extending one base
class).
>
> So the schema for Class = Sexy.HiFi includes both xAP-Audio.Audio
and
> xAP-Audio.Transport, and thus all message blocks from each Class are
> valid in Sexy.HiFi and can thus be combined into the one message?
>
> That seems straightforward to me, but I wonder how often we'll be
> doing multiple blocks in a single xAP message?
>
> I support it in my framework of course, but so far I don't use it
that
> often. Then again, having just said that, I actually do use it in my
> OSD app. This picks up events and sends a xAP-OSD.Display message
with
> a SliMP3 block *and* a TiVo block.
>
> I'm just wondering if we could achieve the same effect sticking with
> single inheritance, but via multiple messages, thus avoiding adding
> features that we can already achieve some other way.

I have thought of one problem with the MI arrangement. What happens
if you want to control more than one "thing" in one message (ie
repeat the same class more than once, in a different control context
each time - perhaps to set a lighting scene) - you can't identify the
significance of each block because it doesn't have a name. You could
solve this easily enough by changing the format of the block name to
be say <class>:<label> where :<label> is optional. It's a
big deal to
change the naming scheme, but it's also a big deal to limit messages
to only controlling a single thing...

Splitting two pieces of control information that belong together into
separate messages is a really bad idea. It means that the receiver
has to be stateful (difficult on say a PIC), and it means that you
can have all sorts of unintended behaviour if messages arrive out of
order or if message gets lost.

Patrick