Re^2: You cannot pass args when calling inner() in Moose?

But if you could pass arguments, you'd break the sub create {my $self = shift;... paradigm

Yes, you have a point. I'm starting to see that Moose corrals you into keeping things in attributes instead of passing values around.

for my $item (@item) {
  $self->i(++$i);
  inner();
}
[download]

Ah nice. But there is a problem. There is not always an inner class... The superclass can be instatiated and run just fine if you dont plan to use perl/gtk to give GUI feedback on data processing. The inner call should only be called if ref $self ne __PACKAGE__

Alternatively, I could always never run the superclass directly and have ::Gtk2 subclass as well as a ::PlainText subclass.

The mantra of every experienced web application developer is the same: thou shalt separate business logic from display. Ironically, almost all template engines allow violation of this separation principle, which is the very impetus for HTML template engine development.

-- Terence Parr, "Enforcing Strict Model View Separation in Template Engines"

Comment on Re^2: You cannot pass args when calling inner() in Moose? Select or Download Code

Replies are listed 'Best First'.
Re^3: You cannot pass args when calling inner() in Moose? by kennethk (Abbot) on Jul 21, 2011 at 17:23 UTC
Why would it matter if there is not necessarily an inner class? Assuming the `i` attribute does not clobber any existing attribute, then this becomes a no-op. And according to Moose::Manual::BestPractices, you should Always_call_inner_in_the_most_specific_subclass	[reply] [d/l]
Re^4: You cannot pass args when calling inner() in Moose? by metaperl (Curate) on Jul 21, 2011 at 19:03 UTC
For the time-being, I have if-then'ed a solution: `sub updateprogress { my ($self) = @_; return unless $self->progressbar; my $frac = frac($self->recordi, $self->recordcount); $self->progressbar->set_fraction($frac->num); }` [download] and then the data processing loop blindly calls this graphic method: `sub manager { my ($Operation) = @_; my @row = $Operation->getnew; my ( @warnings, @fatals ); $Operation->recordi(0); for my $row (@row) { $Operation->recordi( $Operation->recordi + 1 ); $Operation->data($row); $Operation->process; $Operation->updateprogress; } ( \@warnings, @fatals ); }` [download] The mantra of every experienced web application developer is the same: thou shalt separate business logic from display. Ironically, almost all template engines allow violation of this separation principle, which is the very impetus for HTML template engine development. -- Terence Parr, "Enforcing Strict Model View Separation in Template Engines"	[reply] [d/l] [select]


There's more than one way to do things
	PerlMonks