Alain Rastoul wrote:
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 ?
I'm not so much concerned about "typing" in itself , but more about convenience in what I'll tentatively call "searchability" and "observability". If a pragma in the method definition defines the type of its parameter, then in the caller I am still looking at a single method name (#accept:) shared amongst several domains - and <cmd-M> still brings up a mixed list from those domains. Then again, maybe I just described one purpose "typing"? But I'm note sure what using a pragma would add, particularly since I can't see past how would you link invocation and implementation. Using #acceptSomeClass: seems the simplest thing that would work. cheers -ben
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