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