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
|