Alain Rastoul wrote:
Le 08/11/2014 13:19, Ben Coman a écrit :
Thierry Goubier wrote:
Hi Ben,
2014-11-08 7:28 GMT+01:00 Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>>:
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?
It has a nice "a type is documentation for the programmer" effect, so I'd say it could work. It would be interesting to see what it looks like on an external package of a certain size and with users.
At the same time, your issue is also with the fact that filtering the relevant #accept: implementors could be easier, and this is a GUI issue for which we already have propositions (or we can think of some).
Thierry
If you are thinking of scoped-browsing, then I think my particular case just now, that would have been a little constraining. I wasn't really on a task working with OSWindow. I was just bouncing around the system with curiousity. Needing to scope the browser before doing <cmd-M> would add some steps (i.e. friction) over just having methods named #acceptDomainSpecific: .
And I am thinking of another hypothetical case where a third party extends a visitor pattern in a separate package, so if the browser scope was limited to a particular package, then the visitor in the other package would be excluded. But if its done on methodName, a third party extension is implicitly included. hence the use of pragma: a basic contract on the interface of the method that may be useful to the browser to find relevant implementations in all packages.
It seems that it is what you are looking for: find all implementations of accept: anOSWindowOrSubclass ?
I am still not clear on how a pragma could be used here. First I presume you mean to put pragmas in the implementations of #accept, and not in all the callers of #accept. (??) Subsequently, what information in the caller... OSWindowMorphicEventHandler>>handleEvent: morphicEvent := anEvent accept: self. ...when selecting 'accept:' and pressing <cmd-M>, could be combined with the pragmas to provide a filtered list with only the implementations of #accept related to this domain? cheers -ben
cheers -ben