Object: Identity vs. Environment

Joel Shellman joel at ikestrel.com
Thu May 29 05:05:44 UTC 2003


> Since the space that is being cleaved by the distinction #isFoo is the
> space of Objects, it is mathematically most correct to define isFoo in
> Object to return <false> and override that definition to return <true>
> for all classes whose instances belong to the distinction Foo.

The cleaving you are referring to then is 1) every object that is a foo, and
2) every object that is not a foo, right?

However, that same distinction can be made for any class: 1) is an instance
of MyClass, 2) is not an instance of MyClass.

But you wouldn't want an object to be a type of MyClass, and every other
NotEveryOtherClass, would you? In other words, the classes are marking the
"true" side of the distinction but they do not mark the "false" side of the
distinction. So why should you mark the false side of the distinction with
#isFoo?

Similarly, the distinction of an object that has a method on it: 1) object
has a #myMethod on it, 2) object does not have a #myMethod on it.

If I have an object with #myMethod, I shouldn't want to have to put on every
other object #notMyMethod (or a "false" #myMethod) on everything in order to
"cleave" the set of objects, would I?

> The point is that #isFoo is a distinction. A distinction that cleaves
> the space of objects. Thus one definition in object class sets the
> stage by implicitly saying once "everything not declared to be a Foo is
> most certainly not a Foo.

But this statement seems to support what I'm getting at. That you only need
to specify the "true" side of the distinction because once you have that,
"everything not declared to be a Foo is most certainly not a Foo." Aren't
those very words saying that it is unnecessary to declare something "not a
Foo" because it's already implicit because it wasn't declared to be a Foo?
If we accept your statement as true, #isFoo on Object is redundant. Putting
some sort of marker on classes that have Fooness is all that is necessary.

-joel



More information about the Squeak-dev mailing list