SimpleDelegator vs. simple variable?

Hello all,

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

Thanks!

On Mar 14, 2006, at 6:11 AM, Peter F. 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. :wink:

James Edward G. II

On 3/14/06, James Edward G. II [email protected] 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. :wink:

James Edward G. 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
discussionhttp://article.gmane.org/gmane.comp.lang.ruby.general/109237requires
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.

James G. 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. :wink:

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 :slight_smile:
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

2006/3/14, James Edward G. II [email protected]:

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. :wink:

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

On Mar 14, 2006, at 2:16 PM, Robert K. 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 G. II

On 3/14/06, Robert K. [email protected] wrote:

I asked the same question when I wrote the documentation for that

tamper with implemented methods.

Kind regards

robert


Have a look: Robert K. | Flickr

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?

Peter F. 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. :wink:
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

On 3/21/06, Robert K. [email protected] 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 ?

Peter F. 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://c2.com/cgi-bin/wiki?DelegationPattern
http://c2.com/cgi-bin/wiki?search=delegation

Kind regards

robert