[FIX][KCP] KCP-0112-FixCanUnderstand
ducasse
ducasse at iam.unibe.ch
Fri Dec 12 19:19:28 UTC 2003
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
>>>
>>>
>
>
>
More information about the Squeak-dev
mailing list
|