On 10/28/05, Jonathan Scott Duff <[EMAIL PROTECTED]> wrote:
> Roles can hold instance data that will be composed into a class.  What
> I'm saying is that if you have two roles:
>
> role X { has $:foo; }
> role Y { has $:foo; }
>
> And a class that's composed of them:
>
> class Xy does X does Y { ... }
>
> That there will not be two slots for $:foo in Xy, but only one.
>
> But, I'm probably wrong about this as the X role may have methods that
> use $:foo in one way and the Y role may have methods that use $:foo in
> some other, incompatible way, so perhaps there will be a conflict just
> as when there are 2 methods of the same name.

The solution I proposed to Steve is somewhat involved, so let me take a moment.

In my view of objects, there are only behaviors. An attribute is
simply a behavior that will store some value (somehow) when asked and
will return the last value stored (somehow) when asked. The whole
concept of the attribute is to support behaviors that are (ultimately)
used publicly. Hence, from a strict encapsulation POV, the attributes
should be private to the definer.

As such, a role would have private methods that can only be called by
methods defined within that role (stubs aside). Stuff that composes
said role into themselves would only be composing the public API, not
the private API. Those methods that get composed would be able to
access the private methods (attributes or not) that were defined
within the role.

If this solution were to be enacted, then the role wouldn't pollute
the class's attributespace with its attributes and there couldn't be
any conflict between roles or the roles and the classes. This also
extends to attributes and inheritance - the private concept that C++
has. (I don't agree with the protected concept, but private vs. public
is good.)

Doing it any other way leads to the following: if A does rA and B isa
A and B defines an attribute that conflicts with the one provided by
rA, how on earth is that supposed to be detected? Especially given
that the inheritance tree of a class can be modified at runtime.

Rob

Reply via email to