Joel Shellman wrote:
> > 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].
> >
> > That is, every method which asserts that instances of a class have
> > some property would be MORE complicated than the corresponding
> > #isFoo method would have been.
>
> 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) 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.

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

Nothing gained.

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.

It must be noted, however, that one can run into name clashes more easily in 
this manner - other classes using the same symbol for a semantically 
different criterion. That's exactly because my proposal removes the 
centralised knowledge of these things that comes with current practice.

So, yes, I can see, how a package manager could help us with this issue 
(resolution of name clashes). Or maybe one could find better substitutes for 
the kind of guarded clause programming that gave rise to this issue.

-- Lothar

"Walk this world with me"