---Diego Gomez Deck Wrote:
[snip}

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

[snip]

I would like to say a couple of thing here. First the
programmer that wrote the method didn't need a Point, all
he needed was an Object that implemented (or answer) to
certain messages and Probably he thought in a Point in the
moment of implementation. The problem here is that systems
evolve, and if you like to send to pass to that method
another object that implements the needed methods, but that
is not a Point, you can't do that in a strong typed system.

The problem here is, IMHO, that there's a confusion between
type and classes or objects. In the previous example, the
type of the object could be Positionable, but it hasn't to
be Point.

I also think that some sort of hints to the developer would
be very welcome, but those hints are only related with the
type or protocol of the object in that context. The main
problem here is that those types evolve and have to be
categorized (or classified), and (worst of all) named in a
way that makes them helpful.

In this way we have evolving systems with type hints to aid
the developers.

What do you think?

>>bye
>>--
>>Stefan Matthias Aust //

>Cheers,

>Diego Gomez Deck

bye

Jorge Campos