Hello,

>>Smalltalk allow to write code with the minor possible coupling. An object 
>>is coupled with other object only with the messages sent.
>>Point>>+ otherPoint
>>     ^(self x + otherPoint x) @ (self y + otherPoint y)
>>The only requirement for otherPoint is to answer #x and #y messages [*].
>>[*] Answer a message don't means implement a method. Example: a object 
>>using #doesNotUnderstand: can answer to several messages without a method.
>>
>>Let's see the StrongTalk implementation:
>>Point>>+ other <Point> ^<Point>
>>     ^(self x + other x)@(self y + other y)
>>Why this method require a "complete" Point?  In the not typed version, 
>>the requirements is more relaxed.
>
>I'd put this in different words: The types document the implementors 
>intension.

Yes, I agree... But I'd like to complete the sentence with "the intention 
in the moment of writing the method".

>He/She probably (hopefully) tested the code with points and it works.

Yes, and I'll test my code that send otherThingThanAPoint to this 
method.  Then, in this moment I have at least 2 UnitTests than check this 
method.

>What you call "relaxing the requirement" is actually leaking the 
>implementation.

No in my mind.  I say: "I'm using this method in a way that the original 
designer didn't anticipate"

In other words: polymorphism.

>Because you think you know what part of the Point-protocol is really used, 
>you think, you might be able to provide other objects and the methods 
>still work as expected.  That, however, is pure guessing.

Guessing? I have an UnitTest to prove my "guessing".

>Actually, by using the method in another way than expected by the 
>implementor, you get a tight coupling and depedency to that method.

It's your opinion. IMO, the code has smooth coupling than with a "complete" 
Point.

>If you want to use + on other objects, write your own polymorphic 
>method.  Unfortunately, Smalltalk doesn't allow to add another "+" method 
>for other objects.  But that's a problem with the language. Polymorphic 
>multimethods would help here.  Then, you'd simply add
>
>  Foo>>+ other <Foo> ^<Foo>
>
>and have no dependency on the other method any more but you can still use 
>the same polymorphic message "+".

You can use the "double dispatch" pattern (from Smalltalk best practice 
patterns - Ken Beck) without adding more complexity to the language.

>bye
>--
>Stefan Matthias Aust   //

Cheers,

Diego Gomez Deck