2015-06-18 8:37 GMT+02:00 Peter Uhnák <i.uh...@gmail.com>: > 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. :) >
much clearer now, thank you. (First I thought you want a tool to inspect things like "instances of TreeModels") > > Peter > > On Thu, Jun 18, 2015 at 8:12 AM, Tudor Girba <tu...@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.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" >> > >
