> Lothar Schenk <lothar.schenk at gmx.de> wrote:
> Even now it is rather hard to argue this.
> Let's take "#isColor" as our example.
> It is really literally TRUE that most objects are not colours.
> Putting "isColor ^false" in Object has to be better than
> putting "isColor ^false" in hundreds if not thousands of
> other classes.  It's better for Object to "know" that most
> objects are not colours than for every one of *my* classes
> to have to "know" that most objects are not colours.

I guess the way I see it, is that you ARE putting isColor ^false on every
object (except those that override it) when you put it on Object because...
you are (or at least every object that inherits from Object). And so to me
the argument above is to not put #isFoo on Object.

> It is nevertheless true that all objects should
> have a generic method for checking if the particular instance in
> question has Fooness, but not only specifically for Fooness, but
> also for any other criterion of belonging to a particular set.

Sounds good.

> This is similar to the case when I would ask you if you were a
> Kroogleswank.  If you are not a Kroogleswank you needn't even
> know what a Kroogleswank is to reply that you are not.

Which is another reason not to put #isFoo on Object. I don't want my Tangata
to know anything about Kroogleswank's, but if I put an #isKroogleswank on
Object, my Tangata now DOES know something about Kroogleswank's--the fact
that it isn't one.

> Things are not that simple.  Suppose I ask you
> "He tangata a koe?"  (Art thou a "tangata"?)
> If you say "never heard of them, so I'll answer 'false'",
> you'd give the wrong answer.  ("tangata" = person, human being.)

Not necessarily in the machine. Unless the machine has someway to translate
between personhood and tangata than something that fulfills personhood
cannot be counted on to fulfill personhood.

> It's not enough to say "well, you can't be a tangata without
> KNOWING that you are a tangata", because that isn't really true.

Something has to know whether an object is a tangata or not. Either the
object itself, or some other object could know of an alias (such as
personhood) that is equivalent.

[snip remaining]

I tried to address the rest of the post with my other reply. Here is his
examples translated I think:

> You have forgotten inheritance.  Instead of simply writing
>     fulfills: aSymbol
>         ^aSymbol == #Colorness
> in Color, one would have to write
>     fulfills: aSymbol
>         ^aSymbol == #Colorness or: [super fulfills: aSymbol].

One would write in the initializer (or somewhere appropriate):

Color>>somewhere
    dictionaryOfFulfilling add: #Colorness

Another advantage to this sort of thing is that as I mentioned above,
someone might know that two of those Symbolnesses are equivalent, so it
could inform an object that has one. So I'm running around processing a
bunch of #Personhood's and I somehow discover a Tangata. I can then say:

someTangata addFulfills: #Personhood

and ever after it will know that it's also has personhood. There may be
issues with future compatibility (are those two going to be maintained as
aliases?) but this is one way to support aliases if it's necessary to do so
(since it was brought up).

-joel