[FIX][KCP] KCP-0112-FixCanUnderstand

Peter van Rooijen peter at vanrooijen.com
Fri Dec 12 19:52:11 UTC 2003


From: "ducasse" <ducasse at iam.unibe.ch>
> On 12 déc. 03, at 19:44, Julian Fitzell wrote:
>
> > I'm not sure I buy this change either.  It seems awfully
> > special-casey...
> >
> > I mean, the object *does* respond to that message - it does so by
> > returning an error telling you that a subclass should have implemented
> > the method in one case.  If the subclass hasn't implemented the
> > method, this is an error that we should see - we shouldn't just
> > silently ignore that method.
> >
> > Obviously this depends on where #canUnderstand: is being called, but
> > the appropriate behaviour to me seems to be to check whether the
> > object responds to the message, not to consider what it is going to do
> > *when* it responds to the message - that's a slippery slope that we
> > can't go very far down unless we're going to somehow be able to come
> > to a semantic understanding of all arbitrary code.
> >
> > I agree with Peter that this might be better as another interface; at
> > very least it demands some debate before inclusion.
>
> That's why I did not harvest it yet and ask marcus to have a look at it.
> Still I suggest you to look in the image how canUnderstand: is used. It
> is not used in the case where a subclassResponsibility
> would be called. I still do not understand why we would like to get an
> error once we check that the object would really implement a methods.

I think there is another way of looking at this that might be helpful. Let
us look at #canUnderstand: as a companion of #doesNotUnderstand:. It doesn't
seem so far-fetched to think that "Understand" in both selectors has a
related meaning (even though one is on the class and the other on the
instance, so there is some inconsistency there).

If that is indeed a viewpoint we would like to take, then

(someObject class canUnderstand: #someSelector)
    ifFalse: [someObject someSelector]

would be expected to run into a #doesNotUnderstand:, not a
#subclassResponsibility or a #shouldNotImplement or what have you.

If accepted, this would be an argument against the proposed change.

Does the argument make sense?

Regards,

Peter




More information about the Squeak-dev mailing list