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





--

"Every thing has its own flow"