>
>
> There are several different things going on here I think.
>
> 1) Attributes are different from Methods however
> Accessors/Readers/Writers are not. It is kind of a philosophical point
> but Attributes define the data structure that makes up the core of the
> object while methods define the behavior. When you get deeper into the
> MOP it does make a difference.
>
> 2) Delegation is simply a short hand for the common idiom of handing
> off behavior to a sub object. Basically just like your accessory
> example we are replacing the longer sub foo { shift->{fooer}->foo(@_)
> } with the delegation line. This is purely behavioral because fooer is
> a separate object with it's own distinct data. If it weren't the much
> cleaner way to model fooer would be as a Role applied to our *own*
> class.
>
>
You are basically right, philosophically, anyway. I asked myself the same
question when I was writing, "Why was it, again, I didn't just want to apply
the Role?" Now I remember. :-)
Setting aside the fact that delegation doesn't work the way i'd like because of
a bug - this is much more interesting to look at anyway, here it is.
Let's say, you have a Cloud that is implemented with 'Rain'. Your various
objects may want to aggregate the cloud and delegate the behavior instead of
inheriting (via a role) because the Cloud objects will contain the necessary
data that it important to share across the system.
Thus, saying sky->pour, roof->pour, god->pour will use up the raindrops in the
Cloud that's actually doing the raining.
Ok, my metaphor is running out of steam, but you get the idea, particularly if
Cloud opens files and has state.
In implementing this, you will often need access to the attributes along with
the methods. For instance, after pouring the rain, you might check remaining()
or weight() or tail the rain log using file location. I can see a lot of cases
when , in English, we delegate attributes, if you will. Like how much gas does
the Car have? (Attr delegation to Tank). How fast is the computer (delegation
to CPU), how much RAM does it have? and so on. I think, I have convinced myself
in the process of writing that attributes are no different when it comes to
delegation.
The way I solved my problem is via an AUTOLOAD function. It passes everything
that the object supports. It should be made even cleaner if I first check if
the Role implements that method. Is this a good workaround for the bug, do you
think?
