Next][Thread Prev][Thread Next][Message
Re: Re: Class Inheritance
- Subject: Re: Re: Class Inheritance
- From: Stuart Booth
- Date: Sun, 25 May 2003 11:30:00 +0000
On Sun, 25 May 2003 09:50:58 -0000, "Patrick Lidstone"
>> 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
It could still read the Audio.Transport.Meridian block, but only deal
with Audio.Transport items/values, ignoring the rest. This passes:
And if the block was named Audio.Transport, anything not part of the
Audio.Transport block would instead be flagged as invalid. This fails:
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
>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.
xAPFramework.net - a reusable xAP framework for .net
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |