Peter Fitzgibbons
3/21/2006 2:54:00 PM
On 3/21/06, Robert Klemme <bob.news@gmx.net> wrote:
>
> Peter Fitzgibbons wrote:
> > On 3/14/06, Robert Klemme <shortcutter@googlemail.com> wrote:
> >> 2006/3/14, James Edward Gray II <james@grayproductions.net>:
> >>> 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