> > No, you wouldn't do it that way--as you say, that would indeed be bad.
The
> > entire implementation could be in Object. Object would create a
> > dictionaryOfFulfilling and then:
> >
> > Object>>fulfills: aSymbol
> >     ^dictionaryOfFulfilling containsKey: aSymbol
> >
> > (I guess this would be a class method or something, but I'm still new
with
> > smalltalk.)
>
> What you propose (if we'd assume your code would do what you want, which I
> think it doesn't, because it only tells me if a key is in the dictionary,
not
> that the object in question is associated with that key)

If the contract is "if it's in the dictionary than isFoo is true" than all
you have to do is find out if the key is in there. It could be done
differently, but this way works.

> is basically the
> same thing as what current practice does, only current practice uses
Object's
> method dictionary for registering instead of a separate class variable
> dictionaryOfFulfilling.

Fair enough. One could try to argue some obscure things about separating it
into two, but in effect, your point is quite valid.

> In this way the burden of keeping track of specific set inclusion criteria
> (what you call marker interfaces) still resides with Object.

There is no "burden". Object simply has an additional variable, nothing
more. Maintenance of that would be throughout the subclasses.

> My proposal keeps Object free from this. All two consenting parties (a
> provider class and a client class) need to do is to agree on an identifier
> for the criterion and use Object's generic #fulfills: method. Object
really
> never needs to know which classes use a given criterion.

How do you respond to the problem of inheritance? Having to traverse up the
inheritance hierarchy seems way too expensive to me, and lacks flexbility.
In fact, that proposal seems to be nearly indistinguishable from using
#respondsTo. The "agreed upon symbol" would be a certain method. It's the
same thing.

What I am curious to know is why noone has discussed the idea of simply
handling DNU exceptions if #isFoo isn't there. Why not? That seems to make
some sense to me. I don't understand smalltalk exception handling, though,
so I think I'll read up on that this morning.

-joel