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