Tyler wrote:
> I would like to propose a new design heuristic. Anything that causes Ping
> to make a diagram is too complex and must be simplified.
Chip wrote:
> I think this is a fine heuristic, as long as our benchmark is Ping and
> not MarkM. MarkM will make a diagram for anything :-)
Dean wrote:
> 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?
Tyler wrote:
> 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
> inheritance.
Chip wrote:
> 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?
!ping