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