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.
Stef
Julian
ducasse wrote:
Hi Peter Good question. Nathanael will certainly reply but just two points: - if canUnderstand: #foo replies true when a class has a method foo ^ self subclassResponsibility or shouldNotImplement then there is something really wrong in smalltalk....because normally people think that they can call foo on the receiver but this is not the case with those examples. This means that you will never be able to find code from VW or nay other smalltalk that breaks what nathanael proposes because else the code itself breaks in the other dialects :) funny no! - The usage of canUnderstand: should really be restricted. In fact this is a meta level interface functionality and we should have a task force to carefully evaluate the use in the current image as usage of canUnderstand is 99 % of the time a sign of not so well-designed code. Thanks for letting me having fun! This was really cool. Stef On 12 déc. 03, at 18:05, Peter van Rooijen wrote:
From: n.schaerli@gmx.net
from preamble:
"Change Set: KCP-0112-FixCanUnderstand Date: 12 December 2003 Author: Nathanael Schaerli
Fixes canUnderstand so that it deals with abstract methods (i.e., subclassResponsibility and shouldNotImplement) in the right way."!
Natanael,
Are you sure this is wise? How exactly did you decide what is "the right way"?
How do other dialects implement #canUnderstand:? Are they also "wrong"?
If you need the new semantics for something you are working on, why not add another method that does exactly what you want instead of modifying this old-timer?
Regards,
Peter van Rooijen