Re: Re: Class Inheritance

[Stuart Booth]

On Sun, 25 May 2003 09:50:58 -0000, "Patrick Lidstone"
<<a
href="/group/xAP_developer/post?postID=_Qc2esovmabyTOC5DesQcWj0bzSDvelhoVZ4BfTqT4_nkkV1y-_hvDULUndXSJ0gomYYqIveoMA2_zqI">patrick@l...</a>>
wrote:

>> 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.

Ahh, I'm just mentioning the various ways I was interpreting your own
thoughts. Reinterpreting vs Redefining were the two ways I thought of
based on what you'd suggested.

> 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!

Great! I didn't much like that either.

>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.

So here then, a Class of xAP-Audio.Transport.Meridian demands a block
name of Audio.Transport.Meridian.

But an app listening for xAP-Audio.Transport messages could still pick
up the xAP-Audio.Transport components and ignore anything it doesn't
recognise.

It could still read the Audio.Transport.Meridian block, but only deal
with Audio.Transport items/values, ignoring the rest. This passes:

Audio.Transport.Meridian
{
Command=scan
}

And if the block was named Audio.Transport, anything not part of the
Audio.Transport block would instead be flagged as invalid. This fails:

Audio.Transport
{
Command=scan
}

Just a thought on message validation.

>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.

Oh, yes, of course. That makes perfect sense.

S
--
Stuart Booth
xAPFramework.net - a reusable xAP framework for .net

<a href="http://www.xapframework.net/";>http://www.xapframework.net/</a>
<a
href="/group/xAP_developer/post?postID=Qier0wGDvIRGW4QWaz3LlS9rkydHLvjEdKTW2GnB2081IcIMrUm188ZUwNXN3xlIBDSFazaZWvtnKp9W3oY">stuart@x...</a>