Thank you for the pointer, I will look at it. I like the naming convention of Smalltalk, no discussion here :) I thought pragmas where queryables from smalltalk (hence from an implementor browser), but I may be wrong? And to me typing, *when needed*, is a contract on the type of the argument, my point of view, am I wrong ? Alain Le 08/11/2014 10:39, Thierry Goubier a écrit :
Hi Alain,
2014-11-08 10:28 GMT+01:00 Alain Rastoul <alf.mmm.cat@gmail.com <mailto: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