- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Visit/accept method naming philosophy

by Ben Coman

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(a)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 >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> >> > > > >

Nov. 8, 2014

Re: [Pharo-dev] Visit/accept method naming philosophy

by Thierry Goubier

2014-11-08 13:19 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > Thierry Goubier wrote: > >> Hi Ben, >> >> 2014-11-08 7:28 GMT+01:00 Ben Coman <btc(a)openinworld.com <mailto: >> btc(a)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 > > >

Nov. 8, 2014

Re: [Pharo-dev] Visit/accept method naming philosophy

by Alain Rastoul

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(a)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 >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> >> > > > >

Nov. 8, 2014

Re: [Pharo-dev] Visit/accept method naming philosophy

by Alain Rastoul

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(a)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 >>> >>> >>> >> >> >> >> > > > >

Nov. 8, 2014

Re: [Pharo-dev] Should Nautilus use Rubric?

by stepharo

> as soon as Igor put the configuration in the inbox and mark the issue as âfix review neededâ :) so should I do it? Stef > > Esteban > >> On 08 Nov 2014, at 09:14, stepharo <stepharo(a)free.fr> wrote: >> >> When do we get it because we will work on it while other people are on vacation.... ie monday and tuesday with igor and alain. >> >> >> On 7/11/14 14:52, Esteban Lorenzano wrote: >>> Actually, Iâm (finally) about to integrate it (an alpha version). >>> it will be in the image next week :P >>> >>> Esteban >>> >>>> On 07 Nov 2014, at 14:32, Norbert Hartl <norbert(a)hartl.name> wrote: >>>> >>>> I think we should submit TxModel to the vaporware awards 2014 :) >>>> >>>> Norbert >>>> >>>>> Am 07.11.2014 um 14:24 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>> >>>>> I would say yes. >>>>> we would like to have rubric everywhere we need a real editor :) >>>>> (while waiting for the new TxModel, this is the âless pain pathâ, IMO) >>>>> >>>>> Esteban >>>>> >>>>>> On 07 Nov 2014, at 14:07, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: >>>>>> >>>>>> Hi! >>>>>> >>>>>> Is it worth to integrate Rubric into Nautilus? Or is there any reason not to do it? >>>>>> >>>>>> Thank you a lot! >>>>>> Juraj >>> >> > >

Nov. 8, 2014

Re: [Pharo-dev] Visit/accept method naming philosophy

by Ben Coman

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(a)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 >> >> >> > > > >

Nov. 8, 2014

Re: [Pharo-dev] Visit/accept method naming philosophy

by Alain Rastoul

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(a)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 > > > > > > > > >

Nov. 8, 2014

Re: [Pharo-dev] Visit/accept method naming philosophy

by Nicolai Hess

2014-11-08 13:19 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > Thierry Goubier wrote: > >> Hi Ben, >> >> 2014-11-08 7:28 GMT+01:00 Ben Coman <btc(a)openinworld.com <mailto: >> btc(a)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.

Nov. 8, 2014

Re: [Pharo-dev] Visit/accept method naming philosophy

by Alain Rastoul

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(a)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 > > >

Nov. 8, 2014

Re: [Pharo-dev] inria survey

by Ben Coman

Marcus Denker wrote: >> I've completed it, but some ambiguities I encountered... >> >> What is "Vulgarization of scienceâ > > French people think it is the english translation of the french word "vulgarisation scientifique" > http://fr.wikipedia.org/wiki/Vulgarisation > > It seems to be in the english dictionary as âto make popularâ: > http://dictionary.reverso.net/english-definition/vulgarisation English grabs a lot of words from a lot of places. From my preferred dictionary... http://www.merriam-webster.com/dictionary/vulgarisation I note that it says "foreign term - origin french", so I guess that is why french finds it a good "technical" match. However that usage is not in common use. For me, it evokes strong association with negative connotations... http://www.merriam-webster.com/dictionary/vulgar and while the french interpretation gets a look-in with item 3a, I've never seen the term used like that. Now google translate for... http://fr.wikipedia.org/wiki/Vulgarisation says [1] "Popularization - The extension is a form of educational knowledge dissemination seeks to know (and possibly its limitations and uncertainties) to reach a non-expert audience." ...which sounds like what they mean. [1] http://tinyurl.com/m555d8x Maybe something to feed back to the general INRIA population :) HTH, cheers -ben > > (coming from latin I guess lots of languages have it with kind-of-the same meaning.) > For my german ear it sound horrible, as âvulgÃ¤râ has picked up *very* negative > connotations. > > You really do not want to be thatâ¦ or make your research that: > http://www.dict.cc/deutsch-englisch/vulgÃ¤r.html > > > Marcus > > > > >

Nov. 8, 2014