November 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] NAtiveBoost error

by Sven Van Caekenberghe

> On 08 Nov 2014, at 12:33, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: > > About RabbitMQ and others, I did quite some investigations and already use some > (working with MSMQ in dotnet at work). > I could spend months here but would not like to. > > My last question (in fact my real interrogation) here is especially to you, as the Zn developer, > about a server implementation in pharo: > not a true generic enterprise class server, > a very small and simple dedicated server to start with, > like Teapot is with respects to a big http enterprise class server. > I don't really mind not following existing MQ protocols and RFCs (*), it would be dedicated. > (*): except for the reusing part that of course has to be taken into account, > for example websockets. > > Does it sounds realistic to you or totally undoable, and why ? > Did you made experiments in that direction ? > What would be your opinion, and do you have thoughts to share about that ? > > Thanks in advance Zn implements both classic HTTP client & server functionality as well as WebSockets client & server functionality - based on the known standards. It all works pretty well. You can build various things on top of that. You can get quite far performance wise, but it is definitively slower than highly optimised C or C++ code. I think that does not matter in most cases as the network overhead is always a factor. I don't know what you are looking for, I would just do some prototyping and see what happens. > Regards, > Alain > > Le 08/11/2014 11:25, Sven Van Caekenberghe a Ã©crit : >> >>> On 08 Nov 2014, at 11:21, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: >>> >>> Perfectly correct, I agree, >>> and do you have an opinion or pointers about building a streaming server in pharo ? >>> queuing send/receives (nextPut:, next) from producers and consumers ? >> >> Please start by reading https://github.com/svenvc/docs/blob/master/neo/stamp.md >> Don't forget to read a bit about RabbitMQ itself too. >> You can load the code and look at the tests. >> >>> Le 08/11/2014 11:09, Sven Van Caekenberghe a Ã©crit :> >>>>> On 08 Nov 2014, at 10:56, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: >>>>> >>>>> Thank you for reporting this, I have considered using RabbitMQ or other kind of MOM >>>>> (apacheMQ, other JMS or other implementations) but I tend to prefer a full pharo stack >>>>> what I am looking for is streaming (on top of a queuing server I presume). >>>> >>>> RabbitMQ _is_ the queueing server. STAMP/STOMP is a client for both producers and consumers. >>>> >>>> Yes, it is an extra dependency, just like a database, a shared memory cache, a proxy, etc. It fits in the enterprise world view. >>>> >>> >>> >>> >> >> >> > > >

Nov. 8, 2014

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

by Ben Coman

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

Nov. 8, 2014

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

by Alain Rastoul

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

Nov. 8, 2014

OSWindow roadmap

by Ben Coman

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

Nov. 8, 2014

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

by Thierry Goubier

2014-11-08 15:02 GMT+01:00 Alain Rastoul <alf.mmm.cat(a)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(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) > 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 >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> >> > > >

Nov. 8, 2014

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

by Alain Rastoul

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

Nov. 8, 2014

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