In a message dated Thu, 3 Oct 2002, Michael Lazzaro writes:
> On Thursday, October 3, 2002, at 04:25 PM, Michael G Schwern wrote:
> > Class::Delegation?
>
> Yeah, it's one of the best I've seen: it makes sense, does everything I
> want, and is easy to explain even to newbies. The perl5 hash-based
> syntax is still pretty scary, tho.
>
> Dunno, I keep wishing for something that's a one-liner for simple
> cases. I guess something like:
>
> # $.data_manager receives all method calls for which
> # it has a matching public interface.
>
> class DataSnippet {
> attr $data_manager is DataManager receives ( -ALL );
> }
Looks like a simple Perl 6 grammar munge to me--it's a simple postfix
conditional which takes the declaration before it, gets its type (or looks
at the code, TMTOWTDI) and creates accessors in the namspace of the
caller. Doesn't appear particularly magical to me. In fact, if you
didn't mind writing it
attr data_manager => DataManager, receives => -ALL;
you could easily write it in Perl 5 today.
>
> # alternative syntax, also useful on a method-by-method basis...
> # Note that if steer() has an implementation, it's dispatched there
> too.
>
> class Car is interface {
> attr $left_front_wheel;
> attr $right_front_wheel;
> ...
>
> method steer ( ... ) is dispatched( $left_front_wheel,
> $right_front_wheel ) { ... };
> }
This is doable now too:
dispatch steer => $left_front_wheel, $right_front_wheel;
Could be written in Perl 5, simply enough, as
sub dispatch {
no strict 'refs';
my ($method, @dispatchees) = @_;
*{caller()."::$_[0]"} =
sub {
$_->$method(@_) foreach @dispatchees;
};
}
I think my point here is that there are clearly places where we need
stronger built-in support in Perl of some OO concepts. Delegation may not
be one of them--it's easy enough to graft on, and TMTOWTDI may be good
here.
> Incidentally, I think the Car above is an example of why it might be ok
> to allow attributes in interfaces. (I would definitely argue it's ok
> to give default method implementations in interfaces. You don't have
> to if you don't believe in it, but hey, some people prefer it.) You're
> basically saying that the interface attaches these named attribs to
> anything that use it. It usually isn't considered proper, but I don't
> know if it's evil enough to explicitly disallow.
>
> The biggest problem I see with interface attribs myself is
> implementational, not philosophical; if you've got attribs being
> assembled from multiple interfaces, it makes implementation of
> subclasses even more difficult to optimize. (Of course, we already
> have multiple inheritance, so that ship's probably long sailed already.)
I don't understand. A public attribute will have an autocreated accessor.
So put the accessor in the interface, not the attribute. If you put the
attribute in the interface, you've committed to having it as an attribute.
If you decide to turn it into a computed method, you're out of
luck--unless you make the attribute a tied variable itself (gak!).
Trey
