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

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

2015-06-18 8:37 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com>:

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 <tudor@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@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@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"

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 <nicolaihess@web.de> wrote:

2015-06-18 7:23 GMT+02:00 Peter Uhnák <i.uhnak@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

And gmail didn't add the image correctly it seems... ​ On Thu, Jun 18, 2015 at 10:10 AM, Peter Uhnák <i.uhnak@gmail.com> 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

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

Stephan Eggermont <stephan@stack.nl> 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