Forum: Ruby SimpleDelegator vs. simple variable ?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
3203ed0e608d3bfae1e31282e629ffa2?d=identicon&s=25 Peter Fitzgibbons (Guest)
on 2006-03-14 13:12
(Received via mailing list)
Hello all,

Can someone explain to me the reason for SimpleDelegator over using
"just a
variable".

Thanks!
--
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2006-03-14 15:01
(Received via mailing list)
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.   ;)

James Edward Gray II
3203ed0e608d3bfae1e31282e629ffa2?d=identicon&s=25 Peter Fitzgibbons (Guest)
on 2006-03-14 15:53
(Received via mailing list)
On 3/14/06, James Edward Gray II <james@grayproductions.net> wrote:
> library.  We tried and tried, but only ever came up with one semi-
> In short, I suspect it's a not often used feature.   ;)
>
> James Edward Gray II
>
>
>
Lets see if I get this with a metaphor : If I own the Atomic Clock, and
I
give you one of those "auto-updating" watches, I can change the time on
your
watch (the delegated object), even though I don't own the watch anymore
or
even have a reference to it.

I guess that misses it because I think I just described the Observer
pattern.

Hm..

In reference, I'm looking for the reason that GoF Strategy Pattern (ie.
composition) with this
discussion<http://article.gmane.org/gmane.comp.lang.ruby.gene...
anything more than using a variable and wrapping the delegate calls
as necessary.  One suggesting was Forwardable or Delegator, but with
this
mystery over Delegator, and my understanding of duck-typing and
reflection-based methods, I don't get why they would have an advantage.

Thanks for your insight James.

--
8217faf2bfdfa7daf10135d41ddd421e?d=identicon&s=25 Jeff Cohen (jeff)
on 2006-03-14 21:10
James Gray wrote:
> 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.
>
> In short, I suspect it's a not often used feature.   ;)
>

Are there ever opportunities for removing features in the library that
no one seems to use or understand?

I think I understand that we wouldn't want to remove something that
people are relying on, but if something is rare and they don't even help
document it... then I say let's put it to a vote and then toast it :-)
Let's keep things as simple as possible.  Sometimes the size of the
libraries is a bit overwhelming to me.

Just my two pennies.

Jeff
www.softiesonrails.com
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2006-03-14 21:18
(Received via mailing list)
2006/3/14, James Edward Gray II <james@grayproductions.net>:
> 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.

Kind regards

robert
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2006-03-14 21:37
(Received via mailing list)
On Mar 14, 2006, at 2:16 PM, Robert Klemme wrote:

> I'm not so sure about that.  I've certainly used delegator several
> times in my Ruby time.

We didn't call Delegator a seldom used feature with little purpose.
I completely understand how that is useful.  We said SimpleDelegator,
a class included in that library, is seldom used.  It's pretty much a
way to re-implement variable assignment in pure Ruby, and thus, not
all that helpful.

James Edward Gray II
3203ed0e608d3bfae1e31282e629ffa2?d=identicon&s=25 Peter Fitzgibbons (Guest)
on 2006-03-20 23:54
(Received via mailing list)
On 3/14/06, Robert Klemme <shortcutter@googlemail.com> wrote:
> > I asked the same question when I wrote the documentation for that
> >
> tamper with implemented methods.
>
> Kind regards
>
> robert
>
>
> --
> Have a look: http://www.flickr.com/photos/fussel-foto/
>
>
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?

--
5befe95e6648daec3dd5728cd36602d0?d=identicon&s=25 Robert Klemme (Guest)
on 2006-03-21 09:58
(Received via mailing list)
Peter Fitzgibbons wrote:
>>> library.  We tried and tried, but only ever came up with one semi-
>>> 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
3203ed0e608d3bfae1e31282e629ffa2?d=identicon&s=25 Peter Fitzgibbons (Guest)
on 2006-03-21 15:55
(Received via mailing list)
On 3/21/06, Robert Klemme <bob.news@gmx.net> wrote:
> >>>> variable".
> >>> ever come up with.
> >> tamper with implemented methods.
> and for these cases delegation is better.  Also, as long as we do not
>
>
Thanks Robert.  I think I get it now.  Is there a text somewhere that I
can
read up on the theory of object-delegation ?

--
5befe95e6648daec3dd5728cd36602d0?d=identicon&s=25 Robert Klemme (Guest)
on 2006-03-21 16:28
(Received via mailing list)
Peter Fitzgibbons wrote:
>> 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).
> Thanks Robert.  I think I get it now.  Is there a text somewhere that I can
> read up on the theory of object-delegation ?

You're welcome.  The concept is so ubiquitous that any decent book on OO
theory will cover it.

Some links to start with
http://en.wikipedia.org/wiki/Delegation_pattern
http://c2.com/cgi-bin/wiki?DelegationPattern
http://c2.com/cgi-bin/wiki?search=delegation

Kind regards

	robert
This topic is locked and can not be replied to.