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.

cheers -ben