Updated JEP: nestmates

[John Rose]

On Apr 13, 2017, at 3:05 PM, forax at univ-mlv.fr wrote:
> 
> It seems we are all on the same page but some of us talk about the spec and other about the implementation.
> 
> From the spec point of view, i agree with Brian,
> "Every class belongs to exactly one nest",
> - if there is a MemberOfNest attribute, it defines the nest,
> - if there is a NestMembers attribute, it defines the nest-top,
> - if there is no attribute, it defines its own nest.
> and "Every nest has a canonical, consistent nest-top".

Confirmed.  So the attributes are precursor relations which
should not be confused with the final product entity, a nest.

By "implementation" you mean the same thing as I mean
when I say "precursor relations".

(The product entity can be represented unambiguously
by a Class, the nest-top of the nest.  This is what leads
to confusion, because that's not exactly the same thing
as the class which contains the NestMembers attribute,
nor does it *ever* contain the MemberOfNest attribute,
despite being a member of the nest of which it is the top,
nor is it *ever* in the NestMembers list, despite being
a member of that same nest.)

This tricky language is another reason to settle on a reflective
API sooner rather than later, so we have a rigorous notation
for this stuff.  Should it be the precursors or the emergent
Nest entity?  If the latter, should there be a Class.Nest
type or should we take a gamble and use a Class object
to represent the Nest of which it is the nest-top?

— John