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