Types, Makers, and Inheritance
Mark S. Miller
markm@caplet.com
Tue, 03 Nov 1998 19:11:11 -0800
At 01:02 AM 10/19/98 , Ka-Ping Yee wrote:
>> 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!" ?
[#] "Computer Science is always in need of a new aphorism" --Alan Perlis
> _____
> | |
> | | maker objects
> |_____|
>
> ___
> / \
> ( ) instance objects
> \___/
[#] Let's avoid confusion by calling these "slices".
A delegation tower of such slices corresponds to a conventional "instance",
but to avoid a different confusion, we'll refer to this compound object as
an "instance-tower".
> _____
> [_____] 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 /
> |_______| \_____/
[#] Tangential historical observation
Ascii graphics lives more than 20 years after I saw my first bitmap!?! I'm
even more surprised by the return of hand-written markup languages after
the long hard bloody battle for wysiwyg was thought to be won. Progress
sure has a different shape than any of us thought.
With my predictive abilities this poor (hypertext publishing, at least, was
a big deal), I understand the dangers in making decisions based on my sense
of a potential audience, but I have no other choice. Inheritance (as a
syntactically supported pattern of delegation) stays in E. I say this now
in order to provide context for my reply to this message, but I'll explain
why in answer to later mail messages.
[+] This above diagram is great with one exception.
The three slices on the right are shown as slices of one instance-tower,
and so should be labelled "Eric-the-Animal", "Eric-the-Mammal", and
"Eric-the-Dog". One can also think of the whole tower as Eric the Dog,
with the bottom box being "Eric's doggishness".
>Your comment just now led me to draw arrow #4 only from left
>to right, not from right to left. Is this right?
[+] Yup.
>In the following naming table "subject" refers to the thing
>at the tail of the arrow, and "object" the thing at the head.
[#] Some changes with alternatives and commentary:
relationship subject role object role
1. inheritance sub-maker "inherits from" super-maker
I put hyphens in all your compound words to break you of the habit of
spelling compounds withoutmidcaps. ;)
2. delegation sub-slice "delegates to" super-slice
3. sub-typing sub-type "is a subtype of" super-type
3. derivation sub-type "is derived from" super-type
3. up-compatibility sub-contract "extends" super-contract
Except that "sub-contract" is a terrible name, as there is also
"sub-contracting" by delegation in #2, but it goes in the other direction.
The respective three compatible views of what a type is:
a) A set of objects which are members of that type
b) A description of a protocol spoken (or claimed to be spoken) by a set of
objects.
c) A contract that a set of objects obey (or claim to obey)
Btw, no matter how sophisticated one's type-description language, we should
expect most of the obligation of most types-as-contracts to remain in
natural-language text, written and read only by programmers.
4. instantiation maker "instantiates" instance-tower
4. instantiation maker "instantiates" slice
Potential part-whole confusion here. Does each maker instantiate a slice,
or does the bottom maker instantiate an instance-tower? Both views are
true and useful.
5. product-description maker "vends" instance-type
5. spec-sheet maker "advertises" instance-type
Yup, this is the most difficult to name, and I think my suggestion sucks.
(However, in such matters a sucky suggestion is often much better than
none. You may quote me to myself on this. ;))
The intuition here is that the maker presents a type that claims to
describe what the maker makes.
It may also be useful to have an arrow going the other way:
~5. default maker type "is made by" maker
Relationships #5 and #~5 are currently only raised in presenting the Java
API to E, such that the E programmer can pretend it was written in E, and
can substitute E-compatible objects written in E. Anticipating later
email, a Java class necessarily corresponds to two E objects: one for the
java.lang.Class object, and one whose instance methods correspond to the
static methods and constructors declared in the class declaration.
The Class object describes the protocol that its instances respond to (type
as protocol description), it will say whether an object is an instance of
itself (type as set), and its fully qualified class name can, with some
extra conventions, be mangled into the URL for the javadoc that describes
the type as contract. However, the Class object does not itself provide
the ability to create instances of the class. Therefore, a java.lang.Class
object, in E, is considered a type. The E-native notion of types will, in
some ways yet to be specified, follow in their footsteps.
I find it natural to call the object whose instance methods correspond to
the static methods and constructors declared in the class declaration a
Maker, and to consider it to be in the same category as the E Maker notion.
6. membership member "is a member of" type
6. handshake object "speaks" protocol
6. specification service "claims to obey" contract
Except for #5 and #~5, all the above objects and relationships naturally
occur in both E and Java. Even without inheritance, the three object kinds
(maker, instance, and type) and relationships #4, #6, and #3 (instantiates,
type/protocol-description, subtype/supertype) are still issues.
Why is subtype/supertype still an issue? Since you can ask an object for a
description of the protocol it responds to, you can get multiple protocol
descriptions. At this point, it is natural to ask whether one protocol is
upwards compatible from another. This question is meaningful, and can be
adequately answered, without introducing inheritance, interface
declarations, argument or return types, or static type checking. This is a
purely computed form of subtype/supertype. This notion of type would not
allow you to ask a type for its subtypes or supertypes. Computed subtyping
is not derivation.
>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.
[+] Correct.
The methods for the instance's behavior reside in the instance. Of course,
the maker has methods too, but these are only for the maker's behavior.
>If it were the former, it might imply that the instances
>could see their makers.
[+] It is the latter,
but because of the way lexical scoping works out, instances can generally
see their maker. However, as already discussed, clients of the instance
cannot generally see the instance's maker.
>Does relationship 5 exist?
[#] Depends what you mean by "exist".
(Don't worry, I'll try to stay away from metaphysical ratholes.) It is
implied by bringing Java into the E world, but isn't implied for things
written in E. Of course, you want to be able to write things in E that
seem like things in java that have been made to seem like things in E.
(Let me know if I need to try saying this differently.)
>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.
[-] Types play no role during instatiation.
For code written in E, the only innate Animal Type is the object that
results from the miranda "what's my protocol?" method.
> - The Mammal-Maker creates Eric-the-Mammal with innate
> capabilities to the Mammal-Type [not] 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.
[?] What do you mean by "prototype"?
By "prototype", I'm not sure if you meant prototype-based instantiation,
Self's alternative to class-based instantiation. E believes in neither of
these, but in the original tried and true lambda-based instantiation.
Eric-the-Mammal's methods are in the object-expression that evaluates to
Eric-the-Mammal, not in any prototype object.
> - The Dog-Maker creates Fido-the-Dog with innate
> capabilities to the Dog-Type [not] and to Eric as the
> target of delegation for any unmatched method calls,
> together with any methods in the prototype [not] 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?)
[#] Definitely use synchronous calls.
To stitch together asynchronous inheritance of mutable slices, you get into
territory it takes a Dean Tribble to succeed at. (Dean's success at this
helped found the Vulcan Project as PARC, an ancestor of Joule.) E's
strategy is to avoid, rather than solve, problems this hard.
>*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?
[-] It's mostly correct except for preconditions to this *if*.
>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.
[-] Question doesn't seem to apply.
Since E has no natural notion of type derivation (even though it does have
a natural notion of subtyping), and since an object's type is computed and
reported by the object (in KeyKOS terminology, it is an "alleged type",
even though it is *usually* reported by a miranda method which uses the
object's method dispatch table), I think the above question doesn't come
up. Perhaps there's an alternate formulation that's still meaningful?
>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. :)
[?] Let me know whether these explanations succeeded ;)
Cheers,
--MarkM