On 10/14/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> :     I need to stress that I'm not suggesting that the keyword "role"
> : be removed. It won't be the first time we have keywords that mean the
> : same thing, just with a little sugar added. It definitely improves
> : maintainability to have separate keywords for separate ideas, even if
> : they're implemented identically.
>
> Certainly a different keyword can be used to convey a different intent.
> And because there's a different intent, we can have different defaults
> for them, at minimum.
>
> But I think it goes a little deeper than that.  Not to put too fine
> a point on it, classes want to be open, and roles want to be closed.
> Let's not forget that the main point of roles is to commit to units
> of behavior that can be composed into classes (and other roles)
> at compile time.  It's your basic mutable/immutable distinction.
> The compiler can rely on immutable values not changing.

Ok. So, in essence, a role is a class that defaults to being closed
and a class is a role that defaults to being open. Am I rephrasing you
correctly? If so, then they're really the same beast under the hood,
just with different default behaviors.

> Going the other direction, you could also use a class as if it
> were a role, but only by taking a snapshot of its current value.
> If you're planning to modify your base class after that, you'd
> better be using inheritance rather than composition, or the derived
> class won't see the change to the base class, and that would be
> unfortunate.

As you said in the recent class methods thread, it won't be the first
time the programmer would be surprised that the computer did exactly
what it was told to do. If you choose to compose, you're fixing the
behaviors/state at the time of composition, regardless of what happens
after composition. If you choose to inherit, you're not fixing
anything (save when you choose to close).

>  It's bad enough that you might have to notify all
> the existing objects that one of its base classes has been modified.
> Doing that notification to objects of classes that have composed roles
> with compile-time assumptions would be a nightmare of pessimization.
> The first implementation of Perl 6 might not make use of optimizations
> based on compile-time composition, but we need to leave that door open.

Why would that notification need to be done? I, the programmer, chose
to compose class A into class B. If I then change class A, I do -not-
want class B to see those changes. Granted, it's an unmaintainable
pile of dreck, but it's MY unmaintainable pile of dreck. And, Perl
shouldn't get in the way of my ability to create piles of dreck. I
think inheritable class methods are horrid, but I do agree that Perl
should give you as much rope as you want.

Rob

Reply via email to