June 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols

by Nicolai Hess

2015-06-18 7:23 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > Hi, > > I would like to describe some additional behavior for objects when they > are interacting with another objects. > > The prime example is GTInspector; by default to add presentation you > implement a method with "gtInspectorPresentationOrder:". This is fine if > there is just one method like this, but when the object can serve multiple > purposes it can quite mess up the protocol (in my opinion). > > Example of that could be (Spec) TreeModel; there are many methods like > menu:, displayBlock:, childrenBlock: etc. that should be different based on > the particular object. > Do you mean another kind of inspector, not GT-Inspector, but something that uses the same pattern (methods with pragmas) to implement/realize different panes? I don't fully understand the TreeModel example, what would your tool do with all the men/displayBlock/childrenBlock ... - methods? > > However having a method for each of those cases in the observed method is > just a mess. So how could one approach this? > > The first thing that comes to my mind is a visitor. That might possibly > work for code that I've written, but not for spotter/inspector as they work > directly on the target object. > > Thanks, > Peter > >

June 18, 2015

Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols

by Peter UhnÃ¡k

And of couirse FsmIconVisitor is not enough, because TreeModel (menu) might need different icons than someone else.... So, perhaps the question boils down to: "How to add meta-description to object from another package without affecting the object's protocol or code?" ---- For example Roassal's RTElement exposes a dictionary to which I can add random stuff, however from my experience that gets messy fast (since I end up just manipulating symbols in structural/procedural code). Peter On Thu, Jun 18, 2015 at 8:37 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > The worry is caused by the fact that I do not want to pollute the > protocol; this is not just about GTInspector, but also about other classes > such as the TreeModel. > > So, imagine following hierarchy; there are some "base" classes and then > unlimited number of packages, each with their own hierarchy. > > > â > Now I could either have long switch (if/else/isKindOf:/isMemberOf:) in > TreeModel to specify icon, label, children and so forth for each of those > elements which is a) mess, and b) doesn't actually work because not all > packages might be loaded (this is what I have now, and instead of classes I > use symbols... and it's steaming mess). > Alternatively I could somehow use visitor, which would mean that I would > have visitor for each behavior: ChildrenVisitor, IconVisitor, ...; and then > there would be a method for each object. IconVisitor>>bormStateVisitor: ... > There is already visible name conflict (the visitor would have to add the > package name to the method which would mean special methods also on the > object's side) plus the methods themselves are related to the packages, so > basically I would have to have "FsmIconVisitor", "BormIconVisitor", etc. > Which is NxM visitors (number of behaviors x number of packages)... and > that's a lot of code. At this moment this seems like the "best" way, but to > me it feels like a very bad way to do this. > > Not sure if I made it any clearer though. :) > > Peter > > On Thu, Jun 18, 2015 at 8:12 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi Peter, >> >> I am not sure I understand. >> >> Is the worry caused by the fact that when there are multiple gtInspector* >> methods then the API would get polluted? >> >> Cheers, >> Doru >> >> >> >> On Thu, Jun 18, 2015 at 7:35 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >>> Also the problem with visitor here is that I would need X number of >>> visitors for each method (GtInspectorVisitor, DisplayBlockVisitor, ...) not >>> to mention that I would need to have the implementation split among >>> multiple packages, so it is effectively NxM visitors. >>> >>> Peter >>> >>> On Thu, Jun 18, 2015 at 7:23 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>> >>>> Hi, >>>> >>>> I would like to describe some additional behavior for objects when they >>>> are interacting with another objects. >>>> >>>> The prime example is GTInspector; by default to add presentation you >>>> implement a method with "gtInspectorPresentationOrder:". This is fine if >>>> there is just one method like this, but when the object can serve multiple >>>> purposes it can quite mess up the protocol (in my opinion). >>>> >>>> Example of that could be (Spec) TreeModel; there are many methods like >>>> menu:, displayBlock:, childrenBlock: etc. that should be different based on >>>> the particular object. >>>> >>>> However having a method for each of those cases in the observed method >>>> is just a mess. So how could one approach this? >>>> >>>> The first thing that comes to my mind is a visitor. That might possibly >>>> work for code that I've written, but not for spotter/inspector as they work >>>> directly on the target object. >>>> >>>> Thanks, >>>> Peter >>>> >>>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > >

June 18, 2015

Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols

by Peter UhnÃ¡k

The worry is caused by the fact that I do not want to pollute the protocol; this is not just about GTInspector, but also about other classes such as the TreeModel. So, imagine following hierarchy; there are some "base" classes and then unlimited number of packages, each with their own hierarchy. â Now I could either have long switch (if/else/isKindOf:/isMemberOf:) in TreeModel to specify icon, label, children and so forth for each of those elements which is a) mess, and b) doesn't actually work because not all packages might be loaded (this is what I have now, and instead of classes I use symbols... and it's steaming mess). Alternatively I could somehow use visitor, which would mean that I would have visitor for each behavior: ChildrenVisitor, IconVisitor, ...; and then there would be a method for each object. IconVisitor>>bormStateVisitor: ... There is already visible name conflict (the visitor would have to add the package name to the method which would mean special methods also on the object's side) plus the methods themselves are related to the packages, so basically I would have to have "FsmIconVisitor", "BormIconVisitor", etc. Which is NxM visitors (number of behaviors x number of packages)... and that's a lot of code. At this moment this seems like the "best" way, but to me it feels like a very bad way to do this. Not sure if I made it any clearer though. :) Peter On Thu, Jun 18, 2015 at 8:12 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Peter, > > I am not sure I understand. > > Is the worry caused by the fact that when there are multiple gtInspector* > methods then the API would get polluted? > > Cheers, > Doru > > > > On Thu, Jun 18, 2015 at 7:35 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> Also the problem with visitor here is that I would need X number of >> visitors for each method (GtInspectorVisitor, DisplayBlockVisitor, ...) not >> to mention that I would need to have the implementation split among >> multiple packages, so it is effectively NxM visitors. >> >> Peter >> >> On Thu, Jun 18, 2015 at 7:23 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >>> Hi, >>> >>> I would like to describe some additional behavior for objects when they >>> are interacting with another objects. >>> >>> The prime example is GTInspector; by default to add presentation you >>> implement a method with "gtInspectorPresentationOrder:". This is fine if >>> there is just one method like this, but when the object can serve multiple >>> purposes it can quite mess up the protocol (in my opinion). >>> >>> Example of that could be (Spec) TreeModel; there are many methods like >>> menu:, displayBlock:, childrenBlock: etc. that should be different based on >>> the particular object. >>> >>> However having a method for each of those cases in the observed method >>> is just a mess. So how could one approach this? >>> >>> The first thing that comes to my mind is a visitor. That might possibly >>> work for code that I've written, but not for spotter/inspector as they work >>> directly on the target object. >>> >>> Thanks, >>> Peter >>> >>> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

June 18, 2015

Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols

by Tudor Girba

Hi Peter, I am not sure I understand. Is the worry caused by the fact that when there are multiple gtInspector* methods then the API would get polluted? Cheers, Doru On Thu, Jun 18, 2015 at 7:35 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Also the problem with visitor here is that I would need X number of > visitors for each method (GtInspectorVisitor, DisplayBlockVisitor, ...) not > to mention that I would need to have the implementation split among > multiple packages, so it is effectively NxM visitors. > > Peter > > On Thu, Jun 18, 2015 at 7:23 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> Hi, >> >> I would like to describe some additional behavior for objects when they >> are interacting with another objects. >> >> The prime example is GTInspector; by default to add presentation you >> implement a method with "gtInspectorPresentationOrder:". This is fine if >> there is just one method like this, but when the object can serve multiple >> purposes it can quite mess up the protocol (in my opinion). >> >> Example of that could be (Spec) TreeModel; there are many methods like >> menu:, displayBlock:, childrenBlock: etc. that should be different based on >> the particular object. >> >> However having a method for each of those cases in the observed method is >> just a mess. So how could one approach this? >> >> The first thing that comes to my mind is a visitor. That might possibly >> work for code that I've written, but not for spotter/inspector as they work >> directly on the target object. >> >> Thanks, >> Peter >> >> > -- www.tudorgirba.com "Every thing has its own flow"

June 18, 2015

Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols

by Peter UhnÃ¡k

Also the problem with visitor here is that I would need X number of visitors for each method (GtInspectorVisitor, DisplayBlockVisitor, ...) not to mention that I would need to have the implementation split among multiple packages, so it is effectively NxM visitors. Peter On Thu, Jun 18, 2015 at 7:23 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Hi, > > I would like to describe some additional behavior for objects when they > are interacting with another objects. > > The prime example is GTInspector; by default to add presentation you > implement a method with "gtInspectorPresentationOrder:". This is fine if > there is just one method like this, but when the object can serve multiple > purposes it can quite mess up the protocol (in my opinion). > > Example of that could be (Spec) TreeModel; there are many methods like > menu:, displayBlock:, childrenBlock: etc. that should be different based on > the particular object. > > However having a method for each of those cases in the observed method is > just a mess. So how could one approach this? > > The first thing that comes to my mind is a visitor. That might possibly > work for code that I've written, but not for spotter/inspector as they work > directly on the target object. > > Thanks, > Peter > >

June 18, 2015

gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols

by Peter UhnÃ¡k

Hi, I would like to describe some additional behavior for objects when they are interacting with another objects. The prime example is GTInspector; by default to add presentation you implement a method with "gtInspectorPresentationOrder:". This is fine if there is just one method like this, but when the object can serve multiple purposes it can quite mess up the protocol (in my opinion). Example of that could be (Spec) TreeModel; there are many methods like menu:, displayBlock:, childrenBlock: etc. that should be different based on the particular object. However having a method for each of those cases in the observed method is just a mess. So how could one approach this? The first thing that comes to my mind is a visitor. That might possibly work for code that I've written, but not for spotter/inspector as they work directly on the target object. Thanks, Peter

June 18, 2015

Re: [Pharo-users] Grapher bug?

by Alexandre Bergel

You pointed out indeed a default in Grapher. We will fix this in the futureâ¦ Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Jun 17, 2015, at 6:06 PM, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > > > I know ;-) > I just wanted to avoid creating new big collections > > #Luc > > 2015-06-17 21:12 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>>: > Hi! > > Wellâ¦ Building the list of coordinate is not a big deal :-) > { 5 . 1 . 2 . 5 } withIndexCollect: [ :v :index | v @ index ] > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On Jun 17, 2015, at 7:04 AM, Luc Fabresse <luc.fabresse(a)gmail.com <mailto:luc.fabresse@gmail.com>> wrote: >> >> Hi Alex, >> >> Thanks for your answer. >> I misunderstood RTStackedDataSet. >> To me, it does not do what the doc says ;-) >> >> I want to do exactly that: >> >> c := RTGrapher new. >> ds := RTDataSet new. >> ds dotShape color: Color red. >> ds points: {5@1 . 1@2 . 20@3 . 5@4 }. >> ds x: [ :e | e y ]. >> ds y: [ :e | e x ]. >> c add: ds. >> c axisX noDecimal. >> c axisY noDecimal. >> c build. >> c view inspect. >> >> But I would like to not write by hand (or compute) the X values in the data set which are the indexes of the element. >> >> Thanks, >> >> #Luc >> >> 2015-06-16 22:39 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>>: >> Hi Luc! >> >> This is something that is not really intuitive in Roassal. I am not sure whether this is a bug, but until now, we usually disable the labels on the X-axis. >> >> So, your script should be >> -=-=-=-=-=-=-=-=-=-=-=-= >> b := RTGrapher new. >> ds := RTStackedDataSet new. >> ds dotShape color: Color red. >> ds points: #(5 1 20 5). >> ds y: #yourself. >> b add: ds. >> b axisX noLabel; noTick. >> b axisY noDecimal. >> b >> -=-=-=-=-=-=-=-=-=-=-=-= >> <Screen Shot 2015-06-16 at 5.37.44 PM.png> >> >> If you need ticks and labels, you can simply do: >> -=-=-=-=-=-=-=-=-=-= >> b := RTGrapher new. >> ds := RTStackedDataSet new. >> ds barShape width: 10. >> ds barChartWithBarCenteredTitle: #yourself. >> ds points: #(5 1 20 5). >> ds y: #yourself. >> b add: ds. >> b axisX noLabel; noTick. >> b axisY noDecimal. >> >> b >> -=-=-=-=-=-=-=-=-=-= >> <Screen Shot 2015-06-16 at 5.39.28 PM.png> >> >> I hope this solves your problem. >> >> Cheers, >> Alexandre >> >> >>> On Jun 15, 2015, at 6:20 PM, Luc Fabresse <luc.fabresse(a)gmail.com <mailto:luc.fabresse@gmail.com>> wrote: >>> >>> Hi, >>> >>> The doc here [1] says: "Data points may be stacked, meaning that the index of the point in the collection is its X value." >>> >>> When I use the same example as in the doc but with labels and ticks: >>> >>> b := RTGrapher new. >>> ds := RTStackedDataSet new. >>> ds dotShape color: Color red. >>> ds points: #(5 1 20 5). >>> ds y: #yourself. >>> b add: ds. >>> b axisX noDecimal. >>> b axisY noDecimal. >>> b build. >>> b view inspect >>> >>> it seems that y values are not aligned on x ones (i.e. I would expect the first red point to be 1@5). Is it a bug or did I misunderstood something? >>> >>> >>> <Screen Shot 2015-06-15 at 23.18.36.png> >>> >>> >>> [1] https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Grapher/020… <https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Grapher/020…>Grapher.html >>> >>> >>> Thanks, >>> >>> #Luc >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > >

June 17, 2015

Re: [Pharo-users] Woden-Roassal pharo5 inspector bugs

by Natalia Tymchuk

Are there any news? > On 06 May 2015, at 13:00, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Apparently moose will soon move to Pharo 5. Maybe next week or so. > > Alexandre > > > >> Le 6 mai 2015 Ã 04:34, Lusa Nicolas <nicolas.lusa(a)usi.ch> a Ã©crit : >> >> Hi, >> >> thanks for the quick answer, I'll switch back to pharo4 for the moment. >> >> Cheers, >> Nicolas >> >> >

June 17, 2015

Re: [Pharo-users] Grapher bug?

by Luc Fabresse

I know ;-) I just wanted to avoid creating new big collections #Luc 2015-06-17 21:12 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > Hi! > > Wellâ¦ Building the list of coordinate is not a big deal :-) > { 5 . 1 . 2 . 5 } withIndexCollect: [ :v :index | v @ index ] > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > On Jun 17, 2015, at 7:04 AM, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > > Hi Alex, > > Thanks for your answer. > I misunderstood RTStackedDataSet. > To me, it does not do what the doc says ;-) > > I want to do exactly that: > > c := RTGrapher new. > ds := RTDataSet new. > ds dotShape color: Color red. > ds points: {5@1 . 1@2 . 20@3 . 5@4 }. > ds x: [ :e | e y ]. > ds y: [ :e | e x ]. > c add: ds. > c axisX noDecimal. > c axisY noDecimal. > c build. > c view inspect. > > But I would like to not write by hand (or compute) the X values in the > data set which are the indexes of the element. > > Thanks, > > #Luc > > 2015-06-16 22:39 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > >> Hi Luc! >> >> This is something that is not really intuitive in Roassal. I am not sure >> whether this is a bug, but until now, we usually disable the labels on the >> X-axis. >> >> So, your script should be >> -=-=-=-=-=-=-=-=-=-=-=-= >> b := RTGrapher new. >> ds := RTStackedDataSet new. >> ds dotShape color: Color red. >> ds points: #(5 1 20 5). >> ds y: #yourself. >> b add: ds. >> b axisX noLabel; noTick. >> b axisY noDecimal. >> b >> -=-=-=-=-=-=-=-=-=-=-=-= >> <Screen Shot 2015-06-16 at 5.37.44 PM.png> >> >> If you need ticks and labels, you can simply do: >> -=-=-=-=-=-=-=-=-=-= >> b := RTGrapher new. >> ds := RTStackedDataSet new. >> ds barShape width: 10. >> ds barChartWithBarCenteredTitle: #yourself. >> ds points: #(5 1 20 5). >> ds y: #yourself. >> b add: ds. >> b axisX noLabel; noTick. >> b axisY noDecimal. >> >> b >> -=-=-=-=-=-=-=-=-=-= >> <Screen Shot 2015-06-16 at 5.39.28 PM.png> >> >> I hope this solves your problem. >> >> Cheers, >> Alexandre >> >> >> On Jun 15, 2015, at 6:20 PM, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: >> >> Hi, >> >> The doc here [1] says: "Data points may be stacked, meaning that the >> index of the point in the collection is its X value." >> >> When I use the same example as in the doc but with labels and ticks: >> >> b := RTGrapher new. >> ds := RTStackedDataSet new. >> ds dotShape color: Color red. >> ds points: #(5 1 20 5). >> ds y: #yourself. >> b add: ds. >> b axisX noDecimal. >> b axisY noDecimal. >> b build. >> b view inspect >> >> it seems that y values are not aligned on x ones (i.e. I would expect the >> first red point to be 1@5). Is it a bug or did I misunderstood something? >> >> >> <Screen Shot 2015-06-15 at 23.18.36.png> >> >> >> [1] >> https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Grapher/020… >> Grapher.html >> >> >> Thanks, >> >> #Luc >> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > >

June 17, 2015

Re: [Pharo-users] What would be the first code snippet you would show

by Sven Van Caekenberghe

Here are some more https://medium.com/concerning-pharo/elegant-pharo-code-bb590f0856d0 Maybe for teaching, the example should somehow be familiar, recognisable. On the other hand, that might be confusing and lead to too many comparisons. > On 17 Jun 2015, at 21:53, stepharo <stepharo(a)free.fr> wrote: > > Hi > > For the mooc I have a lecture called Pharo Syntax in a nutshell and I would love to get a couple of simple examples > that show the syntax but are not totally boring. > > I thought about something like > > > ZnClient new > url: 'http://localhost:8080/books/1'; > formAt: 'author' put: 'SquareBracketAssociates'; > formAt: 'title' put: 'Pharo For The Enterprise'; > put > > > > Stef >

June 17, 2015