Types, Makers, and Inheritance
Ka-Ping Yee
ping@lfw.org
Mon, 19 Oct 1998 01:02:06 -0700 (PDT)
On Wed, 14 Oct 1998, Mark S. Miller wrote:
>
> I sympathize with your goal, but no. Equality is pervasive (though yet to
> be resolved), and in any case, given containment, could be tested by "A <=
> B && B <= A".
Of course. I wasn't thinking.
> >I note a potentially troublemaking discontinuity here: it looks
> >like objects will not inherit from their Type objects, which
> >means that two (or possibly three) kinds of "isa" are needed:
> >
> > 1. an object "isa(n)" instance created by its Maker and
> > inheriting from things created by parent Makers
>
> There should not be any general protocol, as this is an implementation
> detail that's none of the client's business.
Perhaps also put as: "Don't plan to meet your maker!" ?
I suspect that i may be deeply confused about types and makers.
(I am hoping that, the more i elaborate on my view of things, the
more likely i am to learn what the correct view is.) Let me try
drawing a picture so that we can set about naming its parts and
relationships.
_____
| |
| | maker objects
|_____|
___
/ \
( ) instance objects
\___/
_____
[_____] type objects
________
[_animal_]
^ ^ ^
_______ / | \ _____
| |_5 3 6__/ \
|Animal-| | /Harvey-\
| Maker | -------4-> ( the- )
| | | \ Animal/
|_______| | \_____/
^ | ^
| ___|____ |
1 [_mammal_] 2
| ^ ^ ^ |
___|___ / | \ __|__
| |_5 3 6__/ \
|Mammal-| | / Eric- \
| Maker | -------4-> ( the- )
| | | \ Mammal/
|_______| | \_____/
^ | ^
| ___|____ |
1 [__dog___] 2
| ^ ^ |
___|___ / \ __|__
| |_5 6__/ \
| Dog- | / Fido- \
| Maker | -------4-> ( the- )
| | \ Dog /
|_______| \_____/
Let's see. The six types of relationships here are numbered
on the arrows in the diagram. (Please correct me if any of
the arrows are in the wrong place, or point in the wrong
direction!)
Your comment just now led me to draw arrow #4 only from left
to right, not from right to left. Is this right?
In the following naming table "subject" refers to the thing
at the tail of the arrow, and "object" the thing at the head.
relationship subject role object role
1. inheritance submaker "inherits from" supermaker
2. delegation subinstance "delegates to" superinstance
3. derivation? subtype "is derived from" supertype
4. instantiation maker "instantiates" instance
5. ???
6. membership member "is a member of" type
(Shoot away.)
Hmm. Is it more correct (or rather, more *lucid*) to say that
the methods reside in the maker objects (which is where you
write them in the code), or in the instance objects? My use
of the word "delegation" to some degree assumes the latter.
If it were the former, it might imply that the instances
could see their makers.
Does relationship 5 exist?
Do i even understand this right? Let me try to describe what
happens when Fido is created:
- Client asks the Dog-Maker for a dog.
- The Dog-Maker uses its capability to Mammal-Maker to
ask Mammal-Maker for a mammal.
- The Mammal-Maker uses its capability to Animal-Maker to
ask Animal-Maker for an animal.
- The Animal-Maker creates Harvey-the-Animal with an
innate capability to the Animal-Type and containing
methods defined in the Animal-Maker, and returns
Harvey to the Mammal-Maker.
- The Mammal-Maker creates Eric-the-Mammal with innate
capabilities to the Mammal-Type and to Harvey as the
target of delegation for any unmatched method calls,
together with any methods in the prototype definition
in the Mammal-Maker. It returns Eric to the Dog-Maker.
- The Dog-Maker creates Fido-the-Dog with innate
capabilities to the Dog-Type and to Eric as the
target of delegation for any unmatched method calls,
together with any methods in the prototype definition
in the Dog-Maker. It returns Fido to the client.
(side question: is it better for each submaker to use a call
or an asynchronous send to ask its supermaker for the
superinstance object? can both possibilities have their uses?)
*If* this is at all correct, then relationship 5 must exist
because the maker objects start out with capabilities to the
type objects. (It might not need a name, though.)
Does this make the type object nothing but an identification
stamp, then?
The makers create a series of delegation relationships which
match their inheritance chain; however, there doesn't appear
to be any mechanism by which anyone can be sure that the
type-derivation chain matches the delegation-inheritance chain.
The makers could just put any object in the "type" slots of
their instances, couldn't they? They could even put different
types in the slots on alternate Wednesdays.
Of course, i could be totally confused about how all this
works, in which case i hope i have provoked a corrective
explanation that will revise my understanding. :)
> > 2. an object "isa" thing associated with its Type object
>
> Yup.
Relationship 6.
> > 3. a Type object "isa" subtype of its base types
>
> Yup, but wrong name. While we might say "Joe is a Person" or "Joe is a
> Mammal", we would not say "Person is a Mammal". I have no syntax for
> translating "a Person is a Mammal" (but see the "Omega" logic system
> associated Actors), so instead I say "Person <= Mammal". Types are best
> considered sets (of the instances which are of that type). "<=" among sets
> similarly means "non-strict subset".
Relationship 3.
I'm glad you think of types as sets, because that makes "member"
a reasonable name for relationship 6.
> >Is it a requirement of all Types that they be able to create
> >objects without being given any constructor arguments? Does
> >this lead to the possibility of objects being in some invalid
> >state until initialized?
>
> Your second question explains perfectly why the answer to the first
> question must be no. Smalltalk & JavaBeans got this wrong. Actors, Java &
> E got this right.
I'm glad the answer is "no" here. :) That's what i wanted to
make sure of.
!ping