Visit/accept method naming philosophy
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? cheers -ben
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
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
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 ?
cheers -ben
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
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
Le 08/11/2014 15:02, Alain Rastoul a écrit :
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 plus subclasses of this class that also implements it 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
trying to be more concrete (and still not sure of pragma syntax and capabilities) I wonder if with methods in the image like: OSMorphicEventHandler>>accept: aMouseEvent <pragma: precondition parameter:aMouseEvent isKindOf: OSMorphicEvent> OSXWindowEvenHandlert>>accept: aMouseEvent <pragma: precondition parameter:aMouseEvent isKindOf: OSMorphicEvent> OSMarsWindowEvent>>accept: aMouseEvent <pragma: precondition parameter:aMouseEvent isKindOf: OSMorphicEvent> SignalHandler>>accept: aSignalEvent <pragma: precondition parameter:aSignalEvent isKindOf: SignalEvent> browsing OSWindowMorphicEventHandler>>handleEvent: OSWindowMorphicEventHandler>>handleEvent: morphicEvent := anEvent accept: self. or morphicEvent := anEvent accept: aVariableEvent. current class beeing a subclass of OSMorphicEvent (type of self), and aVariableEvent type beeing known (NEC/NEOController/model ?) it couldn't be possible to find or filter relevant methods for both, excluding SignalHandler (filtering on accept: methods with good pragma signature) ? Regards, Alain
Alain Rastoul wrote:
trying to be more concrete (and still not sure of pragma syntax and capabilities) I wonder if with methods in the image like:
OSMorphicEventHandler>>accept: aMouseEvent <pragma: precondition parameter:aMouseEvent isKindOf: OSMorphicEvent>
OSXWindowEvenHandlert>>accept: aMouseEvent <pragma: precondition parameter:aMouseEvent isKindOf: OSMorphicEvent>
OSMarsWindowEvent>>accept: aMouseEvent <pragma: precondition parameter:aMouseEvent isKindOf: OSMorphicEvent>
SignalHandler>>accept: aSignalEvent <pragma: precondition parameter:aSignalEvent isKindOf: SignalEvent>
browsing OSWindowMorphicEventHandler>>handleEvent: OSWindowMorphicEventHandler>>handleEvent: morphicEvent := anEvent accept: self. or morphicEvent := anEvent accept: aVariableEvent.
current class beeing a subclass of OSMorphicEvent (type of self), and aVariableEvent type beeing known (NEC/NEOController/model ?) it couldn't be possible to find or filter relevant methods for both, excluding SignalHandler (filtering on accept: methods with good pragma signature) ?
Regards, Alain
Thanks for the concrete examples. So you may be right. If you can demonstrate it working reliably, it would be easy enough to rename #acceptXxx: methods back to #accept:. cheers -ben
Alain Rastoul wrote:
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
On a theoretical level, I really don't know :) but I'll put it in practical terms... Option 1 - Estimate the time and risk to implement this with pragmas, (and consider that _you_ will need to develop it, because I don't know how). Option 2 - Estimate the time and risk to rename about thirty methods and callers (for OSWindow), (and consider that I'd be happy to do it). Now considering the mantra 'do the simplest thing that works', which option is preferable? :)
cheers -ben
cheers -ben
2014-11-08 15:02 GMT+01:00 Alain Rastoul <alf.mmm.cat@gmail.com>:
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)
Yes, but do you imagine how complex it would be to tag everything like that? Compared to the simple naming convention suggested by Ben? Thierry
just an idea, tell me if I'm wrong
cheers -ben
cheers -ben
Le 08/11/2014 15:41, Thierry Goubier a écrit :
Yes, but do you imagine how complex it would be to tag everything like that? Compared to the simple naming convention suggested by Ben?
Thierry
Well, I don't know how much would have to be tagged. Not sure everything would have to, only ancestors in my mind, thus excluding a lot of irrelevant subclasses. I'll have to refine that, but not now, I have to leave for the week end. May be I'm wrong and my idea is bad here... From a user (as a programmer) perspective, I would prefer your idea of following naming than to rename each accept method, I prefer to have simple accept: method than a bunch of acceptOSEventHandler: , acceptXxx: etc... just for simplicity. and eventually use NEController (I think it is this class?) to guess for types at some places. Personnally, I don't like much the visitXxx: naming of methods. (just a programmer's opinion). Another thing: for browsing, the old implementor browser with subpanes was useful because you could easily select the right implementor. Regards, Alain
2014-11-08 13:19 GMT+01:00 Ben Coman <btc@openinworld.com>:
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
+1 for better naming. accept is too generic. Anyway, I don't understand why the pattern should dictate function names. Sure, it may help to understand the design, but you can describe this in the class comment. Events are "processed" or "handled", not visited.
2014-11-08 13:19 GMT+01:00 Ben Coman <btc@openinworld.com>:
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.
I wasn't thinking of scoped browsing; but of something else. You see, when you search for implementors in your case, the answer is this: [image: Images intégrées 1] And, what you see, is that on the left you still have the overall structure of the packages: Core->OpalCompiler-Core, etc... (with all the implementors of accept, of course). 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... [image: Images intégrées 2] You see, the scrollbar shows that you have far less results to review, making your query a lot easier. This is the kind of solution I was suggesting. Thierry
cheers -ben
ben pay attention that OSWindow needs a real polish phase. We logged some items to be fixed in the pharo roadmaps on github in Events.md On 8/11/14 07:28, Ben Coman wrote:
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?
cheers -ben
stepharo wrote in "[Pharo-dev] Visit/accept method naming philosophy":
ben pay attention that OSWindow needs a real polish phase. We logged some items to be fixed in the pharo roadmaps on github in Events.md
Thanks for the reference. Actually it answers some questions I had. I had started to review Case 14404 [1] "extend MorphicEventHandler with #mouseOver and replace all uses of MouseOverEventHandler" and thought it might be useful to add some tests of the existing mouseover, which sent me investigating InputEventFetcher. [1] https://pharo.fogbugz.com/default.asp?14404 I had some seed ideas to introduce a class to replace the eventBuffer Array in InputEventFetcher>>eventLoop, but then (besides performance considerations) wondered what was being disposed of when OSWindow was done. I think maybe I could help with: 1. move the logic of the InputEventFetcher to the OSVMWindowDriver (represents the old system within the OSWindow frameworks). -- but I don't see OSVMWindowDriver in build 40360. 2. OSWindowMorphicEventHandler>>dispatchMorphicEvent: anEvent should rewritten with a more efficient. we should remove the use of defer: 3. Adding some tests to document existing sequencing of #handlesMouseOver:, #handlesDoubleClick: etc... 4. General testing. So how can I get started? * I see a mention a while back of needing a custom VM. Is this still the case? Which VM should I use? * I see CI job https://ci.inria.fr/pharo-contribution/job/OSWindow/ started a week ago but currently disabled. * I see two repositories. Which to use? http://smalltalkhub.com/#!/~Pharo/OSWindow http://smalltalkhub.com/#!/~ronsaldo/OSWindow/commits * How to coordinate? cheers -ben
Hi, Sorry if my question sounds stupid and just denotes misunderstanding here but couldn't this kind of "typing" information (or contract ?) be given by pragmas ? Regards, Alain Le 08/11/2014 07:28, Ben Coman a écrit :
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?
cheers -ben
Hi Alain, 2014-11-08 10:28 GMT+01:00 Alain Rastoul <alf.mmm.cat@gmail.com>:
Hi, Sorry if my question sounds stupid and just denotes misunderstanding here but couldn't this kind of "typing" information (or contract ?) be given by pragmas ?
If you want it to be done that way, you need to look into gradual typing; it is a proper solution (see J. Siek research work), which has Smalltalk/Pharo implementations. Pragmas are no better than a naming convention, they add a layer of language on top of Smalltalk, and they don't help with the search for implementors issue (i.e. they are not visible at the point of call). Philosophically, all work done in Smalltalk is a proof that types declarations may not be that usefull. Thierry
Regards, Alain
Le 08/11/2014 07:28, Ben Coman a écrit :
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?
cheers -ben
Thank you for the pointer, I will look at it. I like the naming convention of Smalltalk, no discussion here :) I thought pragmas where queryables from smalltalk (hence from an implementor browser), but I may be wrong? And to me typing, *when needed*, is a contract on the type of the argument, my point of view, am I wrong ? Alain Le 08/11/2014 10:39, Thierry Goubier a écrit :
Hi Alain,
2014-11-08 10:28 GMT+01:00 Alain Rastoul <alf.mmm.cat@gmail.com <mailto:alf.mmm.cat@gmail.com>>:
Hi, Sorry if my question sounds stupid and just denotes misunderstanding here but couldn't this kind of "typing" information (or contract ?) be given by pragmas ?
If you want it to be done that way, you need to look into gradual typing; it is a proper solution (see J. Siek research work), which has Smalltalk/Pharo implementations.
Pragmas are no better than a naming convention, they add a layer of language on top of Smalltalk, and they don't help with the search for implementors issue (i.e. they are not visible at the point of call).
Philosophically, all work done in Smalltalk is a proof that types declarations may not be that usefull.
Thierry
Regards, Alain
Le 08/11/2014 07:28, Ben Coman a écrit :
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?
cheers -ben
Le 08/11/2014 10:39, Thierry Goubier a écrit :
Hi Alain,
2014-11-08 10:28 GMT+01:00 Alain Rastoul <alf.mmm.cat@gmail.com <mailto:alf.mmm.cat@gmail.com>>:
Hi, Sorry if my question sounds stupid and just denotes misunderstanding here but couldn't this kind of "typing" information (or contract ?) be given by pragmas ?
If you want it to be done that way, you need to look into gradual typing; it is a proper solution (see J. Siek research work), which has Smalltalk/Pharo implementations.
Pragmas are no better than a naming convention, they add a layer of language on top of Smalltalk, and they don't help with the search for implementors issue (i.e. they are not visible at the point of call). yes, the point here was to just to search them in an implementor browser if I understood. contracts checking at run time would certainly imply much more work, the bird's eye way could be to dynamically create and compile subclasses that implement the checks and modify/recompile classes that use them ... not trivial at all and may be risky
Philosophically, all work done in Smalltalk is a proof that types declarations may not be that usefull.
thinking to that, sure, one can allways do without, at work, I sometimes I have to practice the explain me what you need, I'll explain you how to do without method, and don't like to do it much when not really justified... I don't like typing because I feel it is too related to implementation, but some kind of basic contract checking (parameters and returns) of a method are useful in other languages. However, I still prefer smalltalk for its elegance and simplicity, the hardest thing to achieve in software, introducing typing would somewhat break this simplicity
Thierry
Regards, Alain
Le 08/11/2014 07:28, Ben Coman a écrit :
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?
cheers -ben
Alain Rastoul wrote:
Hi, Sorry if my question sounds stupid and just denotes misunderstanding here but couldn't this kind of "typing" information (or contract ?) be given by pragmas ?
I'm not so much concerned about "typing" in itself , but more about convenience in what I'll tentatively call "searchability" and "observability". If a pragma in the method definition defines the type of its parameter, then in the caller I am still looking at a single method name (#accept:) shared amongst several domains - and <cmd-M> still brings up a mixed list from those domains. Then again, maybe I just described one purpose "typing"? But I'm note sure what using a pragma would add, particularly since I can't see past how would you link invocation and implementation. Using #acceptSomeClass: seems the simplest thing that would work. cheers -ben
Regards, Alain
Le 08/11/2014 07:28, Ben Coman a écrit :
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?
cheers -ben
Le 08/11/2014 12:39, Ben Coman a écrit :
Alain Rastoul wrote:
Hi, Sorry if my question sounds stupid and just denotes misunderstanding here but couldn't this kind of "typing" information (or contract ?) be given by pragmas ?
I'm not so much concerned about "typing" in itself , but more about convenience in what I'll tentatively call "searchability" and "observability". If a pragma in the method definition defines the type of its parameter, then in the caller I am still looking at a single method name (#accept:) shared amongst several domains - and <cmd-M> still brings up a mixed list from those domains. My thought was that may be here a pragma (or just guessing about parameter name) could help the implementor browser preselect the accept: method you are looking for in the list, among others (implies modifications to implementor browser of course) btw pragma and contracts may be overkill, guessing could do it
Then again, maybe I
just described one purpose "typing"? But I'm note sure what using a pragma would add, particularly since I can't see past how would you link invocation and implementation. Using #acceptSomeClass: seems the simplest thing that would work.
cheers -ben
Regards, Alain
Le 08/11/2014 07:28, Ben Coman a écrit :
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?
cheers -ben
participants (5)
-
Alain Rastoul -
Ben Coman -
Nicolai Hess -
stepharo -
Thierry Goubier