From: Peter Fitzgibbons Date: 2006-03-21T23:53:57+09:00 Subject: Re: SimpleDelegator vs. simple variable ? ------=_Part_30720_10835571.1142952820170 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 3/21/06, Robert Klemme wrote: > > Peter Fitzgibbons wrote: > > On 3/14/06, Robert Klemme wrote: > >> 2006/3/14, James Edward Gray II : > >>> On Mar 14, 2006, at 6:11 AM, Peter Fitzgibbons wrote: > >>> > >>>> Hello all, > >>>> > >>>> Can someone explain to me the reason for SimpleDelegator over using > >>>> "just a > >>>> variable". > >>> I asked the same question when I wrote the documentation for that > >>> library. We tried and tried, but only ever came up with one semi- > >>> reasonable use for it. > >>> > >>> It you wrap something with SimpleDelegator and hand it off to some > >>> method, you could later change the underlying delegation object, even > >>> though you wouldn't have access to the variable the object is stored > >>> in. This still seems like a stretch to me since some event will need > >>> to trigger the change and you could probably just build the API to > >>> hand-off the new object at that point. Still, it's the only use I've > >>> ever come up with. > >>> > >>> In short, I suspect it's a not often used feature. ;) > >> I'm not so sure about that. I've certainly used delegator several > >> times in my Ruby time. Changing the real target (along the lines of > >> strategy / state patterns) is certainly one way to make use of Ruby's > >> delegation classes. A probably more typical approach is when you want > >> to add functionality to something without changing it. You just > >> delegate and implement those methods with changed behavior. This can > >> be necessary if you do not control creation of the instance whose > >> behavior you want to change and do not want or are not allowed to > >> tamper with implemented methods. > > > Hi Robert. I don't understand the difference between your explanation > and > > re-opening the class on the instanciated Object? Does this get into > $SAFE > > level? > > The difference is whether you have a single instance (which you then > modify) or two instances (where you can leave the original unmodified). > At times it's not allowed / desirable to change another instance / class > and for these cases delegation is better. Also, as long as we do not > have selector namespaces, several added methods to a class / instance > may run into naming conflicts which won't happen if ever part of the > code that wants to add a set of functionality creates their own > delegator. Of course there are drawbacks to delegation (i.e. the > multiplication of objects which can make it hard to find the delegators > from the original object). > > Kind regards > > robert > > Thanks Robert. I think I get it now. Is there a text somewhere that I can read up on the theory of object-delegation ? -- ------------------------------ Forget the icing. Bake the Cake! - the epi-centered developer ------------------------------ Peter Fitzgibbons ------=_Part_30720_10835571.1142952820170--