Hi Alain,

2014-11-08 10:28 GMT+01:00 Alain Rastoul <alf.mmm.cat@gmail.com>:

Hi,
Sorry if my question sounds stupid and just denotes misunderstanding here
but couldn't this kind of "typing" information (or contract ?) be given by pragmas ?

If you want it to be done that way, you need to look into gradual typing; it is a proper solution (see J. Siek research work), which has Smalltalk/Pharo implementations.

Pragmas are no better than a naming convention, they add a layer of language on top of Smalltalk, and they don't help with the search for implementors issue (i.e. they are not visible at the point of call).

Philosophically, all work done in Smalltalk is a proof that types declarations may not be that usefull.

Thierry

�

Regards,
Alain

Le 08/11/2014 07:28, Ben Coman a �crit :

This is a general query and something I've wondered several times before
in different situations, but I use OSWindow as an example since that is
what I happen to be looking at this time.

For curiosity I was having a poke around OSWindow and seeing
OSWindowMorphicEventHandler>>handleEvent:
� � �morphicEvent := anEvent accept: self.

I wanted to view the code that could invoke, so I used <cmd-M> on
#accept: to get the implementors, which lists 116 items, many of which
are unrelated.� �Now its not toooo hard to "guess" which implementations
are related, but it would be nicer to guess less.� �Would it be a
reasonable philosophy to distinguish each package's #accept: method by
appending the expect object type, like this... ?

OSWindowMorphicEventHandler>>handleEvent:
� � �morphicEvent := anEvent acceptOSEventHandler: self.

IRVisitor>>visitNode: elem
� � ^ elem acceptIRVisitor: self

ParseNodeVisitor>>visitBlockNode: aBlockNode
� � �aBlockNode statements do:
� � � � �[:statement | statement acceptParseNode: self]

Or does such a convention constrain too much how you can extend a
visitor pattern?

cheers -ben