Object: Identity vs. Environment

Andreas Raab andreas.raab at gmx.de
Sat Jun 7 00:02:05 UTC 2003


[long discussion snipped]

> > 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].
> 
> I do not see how this comes about. If #isColor in Color does 
> not need the call to super, than fulfills: with parameter
> #Colorness should not need it either. Since both expressions
> are semantically equivalent, I would expect them to 
> exhibit the same behavior in respect to inheritance.

They are not. When you send #isFoo to some object you are asking "are you a
Foo" whereas #fulfills: asks "are you an X" (with X being variable). Because
of this you can't rely on the inheritance hierarchy to handle the request
for you. Let's take an example:

Color>>fulfills: aSymbol
	^aSymbol == #Colorness

TranslucentColor>>fulfills: aSymbol
	^aSymbol == #Translucentness

So TranslucentColor no longer fulfills the Colorness aspect. Now, you might
claim that TranslucentColor should include #Colorness in its property list
so something like:

TranslucentColor>>fulfills: aSymbol
	^#(Colorness Translucentness) includes: aSymbol

But this is going to bite you big time once you try to add

Object>>fulfills: aSymbol
	^aSymbol == #Objectness

So, now you start walking around the system, trying to find all the places
where #fulfills: is *ever* implemented (even code that you have no access
to). Since that's plain not going to work you *do* need the super
implementation. And of course, there are cases like the following, which
require even more elaborate schemes:

Object>>isPrintable
	"by default all objects are printable"
	^true

NonPrintableObject>>isPrintable
	^false

Which would mean you'd have to implement it somewhere along the lines of

NonPrintableObject>>fulfills: aSymbol
	aSymbol == #Printable ifTrue:[^false].
	^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.
> 
> As I said, I doubt this. Provide an example of two 
> semantically equivalent cases, where the parameterised
> version necessarily must be more complicated 
> than the unparameterised version.

Well, you got two in the above and I can make an arbitrary number of more
complex ones ;-)

> Then we would also differ in our judgement on having such a 
> "nasty" complex coupled hack as #respondsTo: in Object, wouldn't
> we?
> 
> Or why would you accept parameterisation in one case, but not 
> the other?

Because in the one case the complexity is hidden in a single place (have you
ever had the need to reimplement #respondsTo:?) whereas in the other there
is a _common_ need to extend the properties in question and therefore,
simplicity of implementation is definitely worth a few extra methods.

Cheers,
  - Andreas



More information about the Squeak-dev mailing list