> I would like to propose a new design heuristic. Anything that causes Ping
> to make a diagram is too complex and must be simplified.
> I think this is a fine heuristic, as long as our benchmark is Ping and
> not MarkM. MarkM will make a diagram for anything :-)
But hey... why me? :) I like making diagrams. (Remember the state transition diagram for Promises?) I guess i'm really asking both of you.
> While there's some truth to this :-) it would be a shame to limit oneself to
> things which don't require diagrams (particularly when the diagram is cool).
On aside note, Dean... what's the coolest-looking diagram you've seen on a topic related to our discussion?
> I would like the type object and maker object to be identical (ie: no
> separate type object). I will also reiterate my desire to eliminate
> I agree. While the separation of type and maker has a certain
> conceptual elegance, this does not IMHO come near to offsetting the
> additional cognitive and notational overhead of having yet another
> abstraction to keep track of, explain, code, etc.
You know, i was going to suggest this too, shortly after making that diagram. But i knew that Mark would not have separated them unless there was an important reason for it, and i guessed something similar to Dean's explanation.
But maybe we can compromise (see (a) below).
> Rule #1 of Capability-based Design: Distinctions in authority are
> represented with distinct objects.
So this naturally raises a few questions for me --
(a) Is it possible to place a simplifying layer in front of
this abstraction so that programmers who don't care about the security properties can work with classes in the more familiar way (especially for access to the Java library)? - Since a Maker must know the Type, can the Maker subsume all of the authority of a Type so that the beginning E programmer can simply treat the Maker as the single object representing both? - (other solutions) (b) Exactly what is the protocol for operating on Types anyway? Is it expected that one will compare types by asking an object questions about its Type; or obtaining a Type from an instance object and asking questions of the Type; or obtaining Types from different objects and comparing them externally with EQ or <=? Who will implement <=? If for example the supertype has the authority to assert derivation but the subtype does not, then does that mean that only >= should be allowed (not <=) for Types? (c) Despite all this discussion about the diagram and inheritance no one has even said whether i'm off my rocker yet. Was the diagram in fact accurate at all? Is my understanding correct?