On 11/4/05, Michele Dondi <[EMAIL PROTECTED]> wrote:
> I'm still convinced my remark _partly_ applies in the sense that the
> overall impression is that a vast majority of most common needs is
> addressed by a *subset* of the current features and trying to stuff all
> them in has brought in quite a lot of discussions of which I'm not even
> sure if they've all settled down.
I think a good comparison can be made to Ruby. For work, I've been
learning Ruby this past week (we're going to try out Rails to see if
we like it). As my colleague put it, Ruby has all the P6 features we
want and it's usable now.
Ruby's OO system is 1000% more complex that Perl5's. Yet, it's still a
net win. For one thing, I don't have to write the following anymore
(lifted from a CPAN module I am working on):
sub children {
my $self = shift;
if ( caller->isa( __PACKAGE__ ) || $self->isa( scalar(caller) ) ) {
return wantarray ? @{$self->{_children}} : $self->{_children};
}
else {
return @{$self->{_children}};
}
}
This is in a vain attempt to implement a protected subroutine. In
fact, I really want a private writing accessor with a public reading
accessor, but have absolutely no way to implement that.
Why do I want such a beast? Because I want to GUARANTEE in an absolute
kind of way that, unless my user truly intended to do so, he's not
going to be able to accidentally screw up my internal state.
And, no, I don't want to use inside-out classes. They're "cool" (in
all the good and bad senses of the word), don't play well with other
P5 solutions, and STILL don't provide the necessary granularity. The
problem isn't with $object->{foo} = 3; The problem is with the
subroutines that aren't real methods with correct protection
mechanisms.
So, for a bit of extra complexity, I get peace of mind for myself and my users.
(Oh, and Ruby has first-class block. W00T!)
Rob
