Re: [Pharo-users] Woden not loading anymore
Thanks Stephan to had a look at this Cheers, Alexandre > On Jun 18, 2015, at 7:11 PM, Stephan Eggermont wrote: > > On 18-06-15 10:12, Lusa Nicolas wrote: >> it was a while that I wasn't updating the woden version that I am using in >> my project, so today I thought to give it a try and see if there was >> something new. >> And now I am not able to load woden anymore, what I get is the following >> error message: >> Error: Name not found: WithOpenGLAndExamples > > ConfigurationOfWoden depends on ConfigurationOfOSWindow. > It depends on version #development. Development of OSWindow > happens on Pharo 5. There is no specific (older) version for > Pharo 4. I prefer software to work on both the current release > and the current bleeding edge, but that isn't always possible. > > The ConfigurationOfOSWindow preloaded in 50120 is not the > latest version. I was able to load > > (ConfigurationOfWoden project version: #development) load: #thales > > after loading ConfigurationOfOSWindow-jb.10 > from Pharo/OSWindow > > I tried loading #thales because it doesn't load Roassal2, > which has interesting problems in its configuration (see Moose > mailing list) > > Running the Woden tests didn't seem to work in a reasonable > time frame, but I could just do a > > WDFPSSimpleExample open > > Most others work, until they need some picture files. > > This all on a Ubuntu 15.04 Linux machine. > > Stephan > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-users] Woden not loading anymore
On 18-06-15 10:12, Lusa Nicolas wrote: it was a while that I wasn't updating the woden version that I am using in my project, so today I thought to give it a try and see if there was something new. And now I am not able to load woden anymore, what I get is the following error message: Error: Name not found: WithOpenGLAndExamples ConfigurationOfWoden depends on ConfigurationOfOSWindow. It depends on version #development. Development of OSWindow happens on Pharo 5. There is no specific (older) version for Pharo 4. I prefer software to work on both the current release and the current bleeding edge, but that isn't always possible. The ConfigurationOfOSWindow preloaded in 50120 is not the latest version. I was able to load (ConfigurationOfWoden project version: #development) load: #thales after loading ConfigurationOfOSWindow-jb.10 from Pharo/OSWindow I tried loading #thales because it doesn't load Roassal2, which has interesting problems in its configuration (see Moose mailing list) Running the Woden tests didn't seem to work in a reasonable time frame, but I could just do a WDFPSSimpleExample open Most others work, until they need some picture files. This all on a Ubuntu 15.04 Linux machine. Stephan
Re: [Pharo-users] World lastKeystroke and openInWorld: aPasteUpMorph
On Tue, 16 Jun 2015, Hilaire wrote: Off topic, but I am curious as a teacher: how old the pupils you are teaching to? I use Etoys or Scratch in grade 7 (age about 12 years) and Smalltalk in grade 10 (age about 15/16 years). They are attending regular "Informatik"-courses at Gymnasium, supposed to learn object-oriented modeling and programming. Markus
Re: [Pharo-users] What would be the first code snippet you would show
Stef: +1 about using somethign with ZnClient. Manipulating web pages (getting data, or filling out forms) is something all students can understand and get excited about (versus some of the other traditional code snippets in books). Sven: Wow, nice link! Those are excellent snippets. On Wed, Jun 17, 2015 at 4:13 PM, Sven Van Caekenberghe wrote: > 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 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 > > > > >
[Pharo-users] Athens and radial gradient
Hello, I wanted to use Athens API to define a radial gradient and I saw that the class RadialGradientPaint only had one radius as instance variable and it seemed to me it was passed as the end radius while the start radius was set to 0. Does it mean that if I want to define a start radius different from 0 I need to call the backend directly ? Thanks, Matthieu
Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols
On 18-06-15 13:35, Damien Cassou wrote: Stephan Eggermont writes: ApplicationTreeModelAdapter>>childrenFor: anObject ^mapping at: anObject ApplicationTreeModelAdapter>>childrenFor: anObject ^(mapping at: anObject class) value: anObject the same method with 2 different behaviors. Hmm, still not awake yet? Note to self: do not program in a text editor. childrenFor: anObject | col name | ^ApplicationTreeModelAdapter sharedInstance childrenFor: anObject ApplicationTreeModelAdapter>>register: aOneParameterBlock at: aClass mapping at: aClass put: aOneParameterBlock ApplicationTreeModelAdapter>>childrenFor: anObject ^(mapping at: anObject class) value: anObject DMMindMap class>>registerChildren ApplicationTreeModelAdapter sharedInstance register: [:parent | ^OrderedCollection new] at: self DCDiagram class>>registerChildren ApplicationTreeModelAdapter sharedInstance register: [:parent | OrderedCollection withAll: parent nodes] and you could of course remove the ApplicationTreeModelAdapter sharedInstance register: part and use a pragma Stephan
Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols
Stephan Eggermont writes: > ApplicationTreeModelAdapter>>childrenFor: anObject > ^mapping at: anObject > > ApplicationTreeModelAdapter>>childrenFor: anObject > ^(mapping at: anObject class) value: anObject the same method with 2 different behaviors. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols
Wake up before posting childrenFor: anObject | col name | ^ApplicationTreeModelAdapter sharedInstance childrenFor: anObject ApplicationTreeModelAdapter>>childrenFor: anObject ^mapping at: anObject ApplicationTreeModelAdapter>>register: aOneParameterBlock at: aClass mapping at: aClass put: aOneParameterBlock ApplicationTreeModelAdapter>>childrenFor: anObject ^(mapping at: anObject class) value: anObject DMMindMap class>>registerChildren ApplicationTreeModelAdapter sharedInstance register: [:parent| ^OrderedCollection new] at: self
Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols
childrenFor: anObject | col name | ^ApplicationTreeModelAdapter sharedInstance childrenFor: anObject ApplicationTreeModelAdapter>>childrenFor: anObject ^mapping at: anObject ApplicationTreeModelAdapter>>register: aOneParameterBlock at: aClass mappaing at: aClass put: aOneParameterBlock ApplicationTreeModelAdapter>>childrenFor: anObject ^(mapping at: anObject class) with: anObject DMMindMap class>>registerChildren ApplicationTreeModelAdapter sharedInstance register: [:parent| ^OrderedCollection new] at: self
Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols
Why not try to use TreeNodeModel to define different kind of nodes? On each
node you can redefine the way to get children, the icon, etc.
Then you give these nodes as the tree roots.
Le 18 juin 2015 à 10:10, Peter Uhnák a écrit :
>
> > I don't fully understand the TreeModel example, what would your tool do
> > with all the men/displayBlock/childrenBlock ... - methods?
>
>
> Ah, I should've explained what TreeModel is; it is a Spec UI widget to
> display tree-like structures:
>
>
>
>
> So the way this works is that I give the TreeModel some root object (DCFsm)
> and then blocks that describes some behavior.
> So in childrenBlock: [ :parent | ... ] the block is expected to return child
> elements for the parent.
> In displayBlock: you pass a block that returns the label that you will see..
> e.g. [ :anObject | anObject name , ' (' , anObject class name , ')' ]
> iconBlock: returns the icon for the object and so on and so forth.
>
> So the way I have implemented it right now is something like
>
> ~
> childrenFor: anObject
> | col name |
> name := anObject class asString asSymbol.
> col := OrderedCollection new.
> name = #DMMindMap
> ifTrue: [ ^ col ].
> (anObject isKindOf: DCDiagram)
> ifTrue: [ col addAll: anObject elements ].
> (anObject isKindOf: DCNamedElement)
> ifTrue: [
> name = #BormParticipant
> ifTrue: [ col addAll: anObject nodes ].
> name = #BormActivity | (name = #BormState)
> ifTrue: [ col addAll: anObject outgoing ].
> name = #BormActivity
> ifTrue: [ col addAll: anObject sent ].
> name = #BormCommunication
> ifTrue: [ col addAll: anObject dataFlows ].
> name = #BormCommunication
> ifTrue: [
> anObject hasConstraint
> ifTrue: [ col add: anObject
> constraint ] ].
> name = #BormTransition
> ifTrue: [
> anObject hasConstraint
> ifTrue: [ col add: anObject
> constraint ] ] ].
> ^ col
> ~
>
> Which is unreadable, unmaintainable and nonextensible. All the #Borm* symbols
> actually refer to classes of a completely independent package and repository
> which doesn't even need to be loaded in the system.
>
> I think what Peter means is: the object oriented way to handle different
> types is by dispatching on each type (~ double dispatch, ~ visiting). You
> could need this for different aspects of your application. In the end, the
> same core mechanism will be implemented multiple times. Sadly, minor
> semantics/structural differences will make it hard to abstract this out.
>
> Yes, double-dispatch seems like the apt solution, however it would lead to
> NxM number of classes (as mentioned before). But the more I think about it
> the more I feel that I will not get any better than that.
>
> Peter
smime.p7s
Description: S/MIME cryptographic signature
Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols
2015-06-18 8:37 GMT+02:00 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. :) > much clearer now, thank you. (First I thought you want a tool to inspect things like "instances of TreeModels") > > Peter > > On Thu, Jun 18, 2015 at 8:12 AM, Tudor Girba 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 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 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" >> > >
Re: [Pharo-users] Monticello / OS deadlock ?
2015-06-18 10:32 GMT+02:00 Jose San Leandro : > Hi, > > So far it works perfect. I'll let you know if it happens again. > Thanks. > > Thank you very much! > You're welcome. Just a question: which version of the vm are you using? Or which zeroconf scripts are you using to download Pharo? I made some changes related to OSProcess in the latest vm (and they have been integrated); if, say, you're using the normal Pharo4 vm, then it would mean that your problem was solved by changing the way GitFileTree uses OSProcess. Thierry > > 2015-06-11 23:28 GMT+02:00 Thierry Goubier : > >> Hi Jose, >> >> I have pushed a new version of GitFileTree (the development version for >> Pharo4) with a complete rewrite of the underlying OSProcess use. Could you >> test to see if it solves your deadlocks? >> >> It should also be a tad faster. >> >> Regards, >> >> Thierry >> >> >> Le 03/06/2015 17:03, Jose San Leandro a écrit : >> >>> Unfortunately it doesn't fix it, or at least I get the same sympthoms. >>> >>> >> >> >
Re: [Pharo-users] Monticello / OS deadlock ?
Hi, So far it works perfect. I'll let you know if it happens again. Thank you very much! 2015-06-11 23:28 GMT+02:00 Thierry Goubier : > Hi Jose, > > I have pushed a new version of GitFileTree (the development version for > Pharo4) with a complete rewrite of the underlying OSProcess use. Could you > test to see if it solves your deadlocks? > > It should also be a tad faster. > > Regards, > > Thierry > > > Le 03/06/2015 17:03, Jose San Leandro a écrit : > >> Unfortunately it doesn't fix it, or at least I get the same sympthoms. >> >> > >
[Pharo-users] Woden not loading anymore
Hi, it was a while that I wasn't updating the woden version that I am using in my project, so today I thought to give it a try and see if there was something new. And now I am not able to load woden anymore, what I get is the following error message: Error: Name not found: WithOpenGLAndExamples I am trying to load it into a fresh Pharo 4 image, but no way, it doesn't load. Here are the version and repository I am referring to when trying to load it: version: #jenkins; repository: 'http://smalltalkhub.com/mc/ronsaldo/Woden/main'. Does anyone know what's going on? Cheers, Nicolas
Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols
And gmail didn't add the image correctly it seems...
On Thu, Jun 18, 2015 at 10:10 AM, Peter Uhnák wrote:
>
>> > I don't fully understand the TreeModel example, what would your tool do
>> with all the men/displayBlock/childrenBlock ... - methods?
>>
>
>
> Ah, I should've explained what TreeModel is; it is a Spec UI widget to
> display tree-like structures:
>
>
>
>
> So the way this works is that I give the TreeModel some root object
> (DCFsm) and then blocks that describes some behavior.
> So in childrenBlock: [ :parent | ... ] the block is expected to return
> child elements for the parent.
> In displayBlock: you pass a block that returns the label that you will
> see.. e.g. [ :anObject | anObject name , ' (' , anObject class name , ')' ]
> iconBlock: returns the icon for the object and so on and so forth.
>
> So the way I have implemented it right now is something like
>
> ~
> childrenFor: anObject
> | col name |
> name := anObject class asString asSymbol.
> col := OrderedCollection new.
> name = #DMMindMap
> ifTrue: [ ^ col ].
> (anObject isKindOf: DCDiagram)
> ifTrue: [ col addAll: anObject elements ].
> (anObject isKindOf: DCNamedElement)
> ifTrue: [
> name = #BormParticipant
> ifTrue: [ col addAll: anObject nodes ].
> name = #BormActivity | (name = #BormState)
> ifTrue: [ col addAll: anObject outgoing ].
> name = #BormActivity
> ifTrue: [ col addAll: anObject sent ].
> name = #BormCommunication
> ifTrue: [ col addAll: anObject dataFlows ].
> name = #BormCommunication
> ifTrue: [
> anObject hasConstraint
> ifTrue: [ col add: anObject constraint ] ].
> name = #BormTransition
> ifTrue: [
> anObject hasConstraint
> ifTrue: [ col add: anObject constraint ] ] ].
> ^ col
> ~
>
> Which is unreadable, unmaintainable and nonextensible. All the #Borm*
> symbols actually refer to classes of a completely independent package and
> repository which doesn't even need to be loaded in the system.
>
> I think what Peter means is: the object oriented way to handle different
>> types is by dispatching on each type (~ double dispatch, ~ visiting). You
>> could need this for different aspects of your application. In the end, the
>> same core mechanism will be implemented multiple times. Sadly, minor
>> semantics/structural differences will make it hard to abstract this out.
>
>
> Yes, double-dispatch seems like the apt solution, however it would lead to
> NxM number of classes (as mentioned before). But the more I think about it
> the more I feel that I will not get any better than that.
>
> Peter
>
Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols
>
>
> > I don't fully understand the TreeModel example, what would your tool do
> with all the men/displayBlock/childrenBlock ... - methods?
>
Ah, I should've explained what TreeModel is; it is a Spec UI widget to
display tree-like structures:
So the way this works is that I give the TreeModel some root object (DCFsm)
and then blocks that describes some behavior.
So in childrenBlock: [ :parent | ... ] the block is expected to return
child elements for the parent.
In displayBlock: you pass a block that returns the label that you will
see.. e.g. [ :anObject | anObject name , ' (' , anObject class name , ')' ]
iconBlock: returns the icon for the object and so on and so forth.
So the way I have implemented it right now is something like
~
childrenFor: anObject
| col name |
name := anObject class asString asSymbol.
col := OrderedCollection new.
name = #DMMindMap
ifTrue: [ ^ col ].
(anObject isKindOf: DCDiagram)
ifTrue: [ col addAll: anObject elements ].
(anObject isKindOf: DCNamedElement)
ifTrue: [
name = #BormParticipant
ifTrue: [ col addAll: anObject nodes ].
name = #BormActivity | (name = #BormState)
ifTrue: [ col addAll: anObject outgoing ].
name = #BormActivity
ifTrue: [ col addAll: anObject sent ].
name = #BormCommunication
ifTrue: [ col addAll: anObject dataFlows ].
name = #BormCommunication
ifTrue: [
anObject hasConstraint
ifTrue: [ col add: anObject constraint ] ].
name = #BormTransition
ifTrue: [
anObject hasConstraint
ifTrue: [ col add: anObject constraint ] ] ].
^ col
~
Which is unreadable, unmaintainable and nonextensible. All the #Borm*
symbols actually refer to classes of a completely independent package and
repository which doesn't even need to be loaded in the system.
I think what Peter means is: the object oriented way to handle different
> types is by dispatching on each type (~ double dispatch, ~ visiting). You
> could need this for different aspects of your application. In the end, the
> same core mechanism will be implemented multiple times. Sadly, minor
> semantics/structural differences will make it hard to abstract this out.
Yes, double-dispatch seems like the apt solution, however it would lead to
NxM number of classes (as mentioned before). But the more I think about it
the more I feel that I will not get any better than that.
Peter
Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols
I think what Peter means is: the object oriented way to handle different types is by dispatching on each type (~ double dispatch, ~ visiting). You could need this for different aspects of your application. In the end, the same core mechanism will be implemented multiple times. Sadly, minor semantics/structural differences will make it hard to abstract this out. > On 18 Jun 2015, at 09:15, Nicolai Hess wrote: > > > > 2015-06-18 7:23 GMT+02:00 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. > > 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 > >
Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols
2015-06-18 7:23 GMT+02:00 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. > 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 > >
Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols
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 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 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 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 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" >> > >
