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.

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.

You see, when you search for implementors in your case, the answer is this:

Then, you start the guessing work: It's probably not in Core, not in Developpement either, so you just close them at the top-level... And you keep closing all the categories (or packages) you are guessing as non relevant: Athens-Core, Spec, etc...

cheers -ben