Re: Extensible Types

From: Richard Maine (nospam_at_see.signature)
Date: 07/14/04 

Date: Tue, 13 Jul 2004 19:31:13 -0700

"Gary L. Scott" <garyscott@ev1.net> writes:

>> "A nonsequence derived type that does not have the BIND attribute is
>> an extensible type."
>
> Yup, read that. It defines a condition that makes a type always
> extensible. It doesn't necessarily imply that a sequence type is never
> extensible.

That's the definition of extensible type. I think it is bolded. Yes,
sometimes the words of the standard are a bit confusing about whether
something is a definition or just a condition. The bolding is sometimes
the best way to tell this.

> I guess the other problem is that I don't understand why a
> sequence type can't be extensible. Why does defining the order of the
> components prevent extensibility? It seems like that would facilitate
> extensibility.

A sequence type does more that just define the order of the
components. A very critical property of sequence types is that you
can define "the same" type with completely separate type definitions
in different scoping units. So there is not a single unique
definition of a given sequence type - it can be defined in multiple
places. I really don't recall all the details, but I don't think
there is any "place" to store type signature information so that
things like select type work.

Anyway, though I forget he details, the problems have to do with
such things as select type. If a procedure gets passed an object
of an extended type, it is supposed to be able to figure out
which type that was. The implementation details pass me by at
the moment, though I do recall them being discussed, but that's
the general area at issue. 

-- 
Richard Maine
email: my last name at domain
domain: summertriangle dot net