The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024

Latest message you have seen: Re: Vender ID request


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: Class Inheritance


  • Subject: Re: Class Inheritance
  • From: Patrick Lidstone
  • Date: Sun, 25 May 2003 09:17:00 +0000

--- In <a
href="/group/xAP_developer/post?postID=-_EsBWIW1vSxKVe0V0tWht97kSFZwyvytO5_DWBXGralpJY3DYslRy5M9d6TKUpMwLLgZvqts3P-Y3pbmMykPbCUBMoDWQ">xAP_developer@xxxxxxx</a>,
Stuart Booth <lists@s...> wrote:
> On Wed, 21 May 2003 13:53:38 +0100, "Kevin Hawkins"
> <lists@u...> wrote:
>
> >Topic 1: A base level 'Status' schema that provides for
minimalist
> >essential state reporting for the typical devices that are
prevalent today
> >in the HA world. ON OFF LEVEL etc
> >
> >Topic 2: Discussion around inheritance of classes - for
example if
> >the above Class was defined as XAPSTATUS then should xAPStatus.C-
Bus inherit
> >from xAPSTATUS and further should xAPStatus.C-Bus.Lighting enforce
the
> >inheritance from the C-Bus class.
>
> Gosh, you know, that strikes me as being really near now you mention
> it. I started wondering how you'd specify the 'base' class, but it's
> already there, in the type name, isn't it.
>
> xAP-Audio.Transport
> xAP-Audio.Transport.SliMP3
>
> I could chuck away a separate class I suggested in the xAP-Audio
> schema, that of SliMP3.Transport (although back then I was under the
> impression that Classes had to be Class.Type formatted - you
> subsequently drew my attention to the fact that a.b.c.d etc is
valid).
>
> If I send a message with a Class=xAP-Audio.Transport can I include a
> xAP-Audio.Transport.SliMP3 message block in the body of the
message? I
> am inclined to say no.
>
> If I specify a Class=xAP-Audio.Transport.SliMP3 I should expect any
> block from any of the parent classes.

All this seems eminently sensible, and we've enough real world
experience of writing apps to know that it should work.

A couple of potential spanners in the works:

- What about polymorphism? (For those that don't have a CS
background, polymorphism is, roughly speaking, the ability to
redefine an attribute in a derived class. 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).

- What about multiple inheritance? (Where a new class is derived by
combining two base classes, not simply by extending one base class).

I haven't thought this through at length, but my first take on this
is:

- For polymorphism: Just don't allow it.

- For MI: Can this be done through multiple message bodies, where the
message body reflects base classes? I think this might actually be
quite neat.

E.g. A multifunction device with a cd player and amp could
encapsulate a base class from xap.transport and xap.audio in the same
message by using multiple blocks.

xap-header
{
..
class=sexy.hifi
..
}

xap.transport
{
...
mode=play
...
}

xap.audio
{
...
vol=10
...
}

Obviously the base classes could be extended if required to allow for
xap.audio.sexy.hifi and xap.transport.sexy.hifi derivatives, each
inheriting from the respective base classes.

Am I barking mad, or is this actually a very cunning scheme? There
has to be flaw, it's all too tidy!

Patrick






xAP_Development Main Index | xAP_Development Thread Index | xAP_Development Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.