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