Proposal for some non-upwards-compatible changes

[Mark S. Miller]

At 11:47 AM 1/29/99 , Bill Frantz wrote:
>At 09:37 AM 1/29/99 -0800, Mark S. Miller wrote:
>>Therefore the isa(Type) query is redundant and possibly
>>dangerous, so I'd like to remove it.  Why dangerous?  "obj isa(Type)" is
>>asking the object's opinion, whereas "Type(obj)" is asking the Type's
>>opinion.  My sense is the latter is less likely to cause confusion about
>>who to trust with what.  No code in the checked in source tree is currently
>>using isa.
>
>[-] ...
>... The alleged type protocol could give 3 answers, ...

[-] Indeed it can.  I think you misunderstand my proposal.

If you reread my earlier message, you'll see I'm proposing we *keep* the
basic alleged type query (look for "protocol"), which returns a Type
object, and that we keep the protocol among Type objects that allows us to
ask if one Type is alleged to be a subtype of another.  Therefore, we *can*
still get the object's opinion about whether it claims membership in some type:

	obj protocol <= type

We also already have a message on a type that will verify that an object is
a member of the type (as well as potentially performing trivial coercions):

	obj := type(obj)

If this returns successfully (ie, doesn't throw an exception) then the type
is claiming that the object as returned is a member of the type.  This is
the Joule verifier technique, and only succeeds if it can strip away any
transparent forwarders that would make the type's claim meaningless.

Given all this, I propose simply to remove the test

	obj isa(type)

from the MirandaMethods, even though it's trust-equivalent to the still
possible

	obj protocol <= type

I want the habitual case to have the more intuitive security properties.
I'm guessing is that "isa" is simple enough to become a habit, but that it
has less intuitive properties.  And I'm guessing that Joule-like
verification is intuitive enough to encourage it instead.

Are these guesses plausible?

Btw, if Vector, Hashtable, and Foo actually describe three different
*facets*, as in separate behaviors over the same state, then the issue
doesn't arise.  Each of your facets would simply allege to be of the
corresponding type.  Perhaps you meant for foo to be a single-facet-object,
where this one behavior responds to the union of Vector, Hashtable, and Foo
messages (assuming there's no conflict)?  In this case, even without "isa",
foo could still allege membership in all three types by returning (in
response to "protocol") a Type object that alleges to be <= each of Vector,
Hashtable, and Foo.  As long as all three of

	foo protocol <= Vector
	foo protocol <= Hashtable
	foo protocol <= Foo

succeed, we're cool.  Btw, note the difference between "a <= b" and "b >=
a".  The first asks a's opinion while the second asks b's opinion.  This is
as true for numbers and sets as it is for types.