[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
|