Hi Ben,

2014-11-08 7:28 GMT+01:00 Ben Coman <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

�

cheers -ben