> I do not agree with this assertion. I've seen closure based solutions
> and OO versions both scale, and both fail. They are appropriate for
> different problems, and different designs. But as long as you know
> what they are (and aren't) good at, you can choose either.
I'd agree. I've done quite a few "closure constructors" like this myself:
sub constructor {
my($name,$count)=@_;
my $closure=sub{
$count++;
print "incremented $name to $count\n";
};
return $closure;
}
This sort of thing returns a variable that acts like an "object"
as far as I'm concerned. And it has zero linguistic overhead.
To do that in a class, you have to have a lexical container
or put it in a separate file. declare the package. create a
constructor subroutine, bless it, and create a incrementor
method/subroutine.
{
package increment;
sub new{ return bless({Name=>shift(@_),count=>shift(@_)}), 'increment'); }
sub inc{ my $obj=shift(@_); $obj->{count}++;
print "incremented ".($obj->{Name})." to ".($obj->{count}."\n";
}
}
that's kinda clunky. It's a lot of line noise.
If perl had more "high minded" classes, I"m not sure how it would look.
{
package increment;
use Moose;
has $name;
has $count;
sub inc{
# I don't use moose, making htis up:
$self=shift(@_);
$self->count() = $self->count() + 1;
print "incremented ".($self->name())." to ".($self->count())."\n";
}
}
I gotta say, the Moose.pm documentation started in second gear
and stripped my clutch.
_______________________________________________
Boston-pm mailing list
[email protected]
http://mail.pm.org/mailman/listinfo/boston-pm
