HaloO,
Autrijus Tang wrote:
On Thu, Jul 28, 2005 at 09:27:00AM -0700, Larry Wall wrote:
Or maybe Any really does mean "Object" and we're just viewing our
hierarchy too strictly if we make every relationship "isa". That's one
thing that neither this formulation nor Thomas's are making very
clear--which type relations are really subclassing, which are role
composition, and which are subtype constraints.
Well I would make all types predicate based. The isa relation of
an object to the class it was instanciated from is just one amongst
many others like doing a role or object structure. And the inheritance
hierarchy is mostly irrelevant for typing an object. This is one of
the difficulties I have with the metric MMD which relies completely
on the count of class derivation levels.
I currently have the following model in mind. The compiler collects
type information from so-called special forms and stores it in a
strictly tree shaped repository called the name space. User code
can query this structure by means of the :: forms. The type lattice
is then build at CHECK time on top of or from this information. In
particular I don't make a distintion between subtype, role, class,
sub or method special forms. This implies that where clauses are
restricted in the contructs allowed in them and the referential
environment accessible to them.
FWIW, I've been reading up on Scala's formulation of trait/class/delegation
hierarchy, and I feel a bit like flipping through a puzzle book to look
at the hints, if not answers. :-)
The Scala type hierarchy splits from the Any root into the two realms
of value types and referential types in good tradition with Java.
This split is located in my type lattice below the $Item type
where \Ref, Value, Undef, Inf and Junction lie nicely parallel to
each other.
--
TSa
