Le 08/11/2014 14:37, Ben Coman a �crit :

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. (??)

yes that's it

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?

implementor browser would have to maintain some dictionary of classes/methods/pragmas implementations of certain kinds,
by searching at run-time in the image (at least the first time)

knowing that the� edited class is a OSMorphicEvent subclass (for example)
and finding in it's list/dictionary one or several
accept: method implementations that has the
<pragma: pre-contract: 'self isKindOf: OSMorphicEvent'>
on a parameter
couldn't the browser preselect one and/or filter them?
(pragma syntax fictious and wrong here of course)

just an idea, tell me if I'm wrong

cheers -ben

cheers -ben