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). yes, the point here was to just to search them in an implementor browser if I understood. contracts checking at run time would certainly imply much more work, the bird's eye way could be to dynamically create and compile subclasses that implement the checks and modify/recompile classes that use them ... not trivial at all and may be risky
Philosophically, all work done in Smalltalk is a proof that types declarations may not be that usefull.
thinking to that, sure, one can allways do without, at work, I sometimes I have to practice the explain me what you need, I'll explain you how to do without method, and don't like to do it much when not really justified... I don't like typing because I feel it is too related to implementation, but some kind of basic contract checking (parameters and returns) of a method are useful in other languages. However, I still prefer smalltalk for its elegance and simplicity, the hardest thing to achieve in software, introducing typing would somewhat break this simplicity
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