gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols

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

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 <[hidden email]> 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

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 <[hidden email]> 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 <[hidden email]> 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"

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 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