Diego Gomez Deck wrote:

> 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.  He/She probably (hopefully) tested the code with points and 
it works.  What you call "relaxing the requirement" is actually leaking 
the implementation.  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.

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

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 "+".

bye
-- 
Stefan Matthias Aust   //
www.3plus4software.de // Inter Deum Et Diabolum Semper Musica Est