- Pharo-dev - lists.pharo.org

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

by Ben Coman

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. cheers -ben

Nov. 8, 2014

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

by Alain Rastoul

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 >>> >>> >>> >>> >>> >> >> >> >> > > > >

Nov. 8, 2014

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

by Ben Coman

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 >> >> >> >> >> > > > >

Nov. 8, 2014

Re: [Pharo-dev] NAtiveBoost error

by Alain Rastoul

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 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] NAtiveBoost error

by Sven Van Caekenberghe

> 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] NAtiveBoost error

by Alain Rastoul

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 ? 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] NAtiveBoost error

by Sven Van Caekenberghe

> 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 Alain Rastoul

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

Nov. 8, 2014

Re: [Pharo-dev] NAtiveBoost error

by Alain Rastoul

Hi Phil, 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). Regards, Alain Le 08/11/2014 10:43, phil(a)highoctane.be a Ã©crit : > I have been using Pharo successfully with RabbitMQ. > > Phil > > Le 8 nov. 2014 10:16, "Alain Rastoul" > <alf.mmm.cat(a)gmail.com > <mailto:alf.mmm.cat@gmail.com>> a Ã©crit : > > Very interesting pointers, thank you Sven. > Pure Pharo sounds really good to me, I lost my appetite for > debugging multithreaded C or C++ > (am I aging ?) and I need some kind of MOM functionality for my > project, that was the > starting point of my ZeroMQ rants. was ramblings here not rants (sorry for my bad english) > In fact, I am looking for a "SOM" (streaming) server as a part of my > musing project > which is about clustering and parallel processing with pharo: > essentially next, nextput: functionalities to PUSH/PULL pools > (may be PUB/SUB REQ/RECV or others?) with some controlling, > signaling and monitoring. > I have the feeling that based on your excellent work in zinc, it should > not be that difficult to built it on top, but may be you know a > project of that kind > I could reuse ? > Do you know about some kind of MOM server in Pharo ? > Or a STOMP or alike server I could vampirize ? > > Thank you > > Alain > > Le 08/11/2014 09:09, Sven Van Caekenberghe a Ã©crit : > > > On 08 Nov 2014, at 00:23, Alain Rastoul > <alf.mmm.cat(a)gmail.com > <mailto:alf.mmm.cat@gmail.com>> wrote: > > BTW, I have the websocket B plan for that (first tests make me > think it could be a better plan for my needs). > It will be a different animal, but interesting too. > > > About Zinc Web Sockets: > > https://github.com/svenvc/__docs/blob/master/zinc/zinc-__websockets-paper.md > <https://github.com/svenvc/docs/blob/master/zinc/zinc-websockets-paper.md> > > But there is also 'STAMP', a STOMP implementation, which is a > generic message queue client: > > https://github.com/svenvc/__docs/blob/master/neo/stamp.md > <https://github.com/svenvc/docs/blob/master/neo/stamp.md> > > Both are pure Pharo. > > Sven > > > >

Nov. 8, 2014

Re: [Pharo-dev] NAtiveBoost error

by phil＠highoctane.be

I have been using Pharo successfully with RabbitMQ. Phil Le 8 nov. 2014 10:16, "Alain Rastoul" <alf.mmm.cat(a)gmail.com> a Ã©crit : > Very interesting pointers, thank you Sven. > Pure Pharo sounds really good to me, I lost my appetite for debugging > multithreaded C or C++ > (am I aging ?) and I need some kind of MOM functionality for my project, > that was the > starting point of my ZeroMQ rants. > In fact, I am looking for a "SOM" (streaming) server as a part of my > musing project > which is about clustering and parallel processing with pharo: > essentially next, nextput: functionalities to PUSH/PULL pools > (may be PUB/SUB REQ/RECV or others?) with some controlling, signaling and > monitoring. > I have the feeling that based on your excellent work in zinc, it should > not be that difficult to built it on top, but may be you know a project of > that kind > I could reuse ? > Do you know about some kind of MOM server in Pharo ? > Or a STOMP or alike server I could vampirize ? > > Thank you > > Alain > > Le 08/11/2014 09:09, Sven Van Caekenberghe a Ã©crit : > >> >> On 08 Nov 2014, at 00:23, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: >>> >>> BTW, I have the websocket B plan for that (first tests make me >>> think it could be a better plan for my needs). >>> It will be a different animal, but interesting too. >>> >> >> About Zinc Web Sockets: >> >> https://github.com/svenvc/docs/blob/master/zinc/zinc-websockets-paper.md >> >> But there is also 'STAMP', a STOMP implementation, which is a generic >> message queue client: >> >> https://github.com/svenvc/docs/blob/master/neo/stamp.md >> >> Both are pure Pharo. >> >> Sven >> >> > > >

Nov. 8, 2014