Re: V4 Data Types: Request for tagged unions

[Benjamin Franksen <benjamin.franksen@bessy.de>]

On Thursday 16 June 2005 15:26, Ralph Lange wrote:
> Benjamin Franksen wrote:
> >On Thursday 16 June 2005 12:55, Benjamin Franksen wrote:
> >>On Wednesday 15 June 2005 23:12, Andrew Johnson wrote:
> >>>To step back a little: I don't understand why your states have
> >>>parameters, and what you could do with them - presumably I can't
> >>>put a CA monitor on a member of a tagged union (what happens to
> >>> the monitor when the state changes and the member no longer
> >>> exists?).
> >>
> >>It must disconnect, indicating that the value in question no longer
> >>exists. Note that a similar question must be answered for the case
> >> of adding/removing views. Here, too, the client will need to
> >> receive notification that a certain value is no longer available.
> >> We could make this a dedicated event type so that clients can
> >> react in a generic way to such conditions.
> >
> >Let me state this more precisely:
> >
> >The very idea of a tagged union implies that independent read or
> > write access to properties subordinate to a certain tag hardly
> > makes sense. I cannot change, nor query, the scanRate of a record,
> > as long as I am not certain that the tag is 'Periodic'. However,
> > subscribing to merely a certain subordinate property might reduce
> > system load.
> >
> >The problem is that changing the tag independently brings the other
> >subordinate properties to an undefined state and this is something
> > we can't handle because we don't have a representation for "no
> > value here". Thus, at least write access must provide all values
> > every time (i.e. tag + add. properties), while reading and
> > subscribing to either tag only or other properties can be allowed
> > but must fail in case of unavailability.
>
> Hm. I don't see any problem with my original idea to have the write
> traversal for a tagged union (exactly like the read traversal) first
> provide the tag and then only the properties that are valid for the
> new tag value. Valid write operations would succeed, invalid
> operations would fail, no meaningless properties being provided in
> the process.

Yes, exactly. I didn't mean 'problem' with regard to implementation via 
DA. I merely meant to explore the design space.

Ben