From: "ducasse" ducasse@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