Opened by flowdy at 2012-11-06 22:47
User since
2012-08-03
45 Artikel
BenutzerIn
2012-08-03
45 Artikel
BenutzerIn
Danke murphy, deine zweite Idee gefällt mir schon gut. Einer hypothetische Dokumentation wäre dann aber auch darauf hinzuweisen, dass return sich nur auf den Aufruf von climb_up() bezieht, wenn die TopNode erreicht ist, es also keinen weiteren Durchlauf der internen Schleife gibt. Interna in der Schnittstellendoku sind für mich nun grundsätzlich suboptimal.
Habe mir gedacht, dass das auch umgekehrt gehen müsste:
Das Problem, aber vielleicht ist es auch kein Problem, sondern würde auch der Verständlichkeit und Wartbarkeit des Codes durchaus dienen, veranschauliche ich an einem möglichen Beispielcode zu &Node::climb_up() in der Doku:
Ist das gutes Design? Weiß nicht. Ich glaube, my $closure = $node->climb_up(); have_fun($_) while $_ = $closure->() ist dann doch einen Deut besser. Ich kann es ja so machen, das climb_up() bei !@_ eine Closure zurückgibt, andernfalls eben so verfährt wie dargestellt.
EDIT: Das ist dann aber auch nicht kürzer als while ( $node = $node->parent_row ) {...}, ergo kann ich auf die Aufrufalternative ganz verzichten, ehrlich gesagt auch auf Node::climb_up überhaupt. Insofern eignet sich das Closure-while-Verfahren wie auch das mit $onTop_return (bzw. $return_ifLast oder irgendwas) nur, wo die Auswahl des jeweils nächsten zu bearbeitenden Knotens komplizierter ist, also sich eine Auslagerung lohnt.
Danke!
flowdy
Last edited: 2012-11-08 14:17:34 +0100 (CET)
Habe mir gedacht, dass das auch umgekehrt gehen müsste:
Code (perl): (dl
)
1 2 3 4 5 6 7 8 9 10 11 12 13
sub Node::climb_up { my ($self, $proc) = @_; my ($magic, @return); my $return_onTop = sub { @return = @_; die \$magic; }; COND_CLIMB: while ( $self = $self->parent_row ) { eval { @return = $proc->($self, $return_onTop) }; if ( $@ ) { $@ == \$magic ? next : die $@; } else { last COND_CLIMB; } } return @return; }
Das Problem, aber vielleicht ist es auch kein Problem, sondern würde auch der Verständlichkeit und Wartbarkeit des Codes durchaus dienen, veranschauliche ich an einem möglichen Beispielcode zu &Node::climb_up() in der Doku:
Code (perl): (dl
)
1 2 3 4 5 6 7 8 9 10 11 12 13
=head2 SYNOPSIS ... $node->climb_up(sub { my ($ancestor, $onTop_return) = @_; my $ret = $ancestor->doSomething(); return if $ret->smells(); # climb_up immediately returns () return do_whatever_with($ret); # i.e. any return values untouched $onTop_return->(@ignore_if_not); # Don't forget at the end! # otherwise ancestors' line processed ends by the parent # (blame perl it'd enforce an implied C<return @last_expr_val;> ) }
Ist das gutes Design? Weiß nicht. Ich glaube, my $closure = $node->climb_up(); have_fun($_) while $_ = $closure->() ist dann doch einen Deut besser. Ich kann es ja so machen, das climb_up() bei !@_ eine Closure zurückgibt, andernfalls eben so verfährt wie dargestellt.
EDIT: Das ist dann aber auch nicht kürzer als while ( $node = $node->parent_row ) {...}, ergo kann ich auf die Aufrufalternative ganz verzichten, ehrlich gesagt auch auf Node::climb_up überhaupt. Insofern eignet sich das Closure-while-Verfahren wie auch das mit $onTop_return (bzw. $return_ifLast oder irgendwas) nur, wo die Auswahl des jeweils nächsten zu bearbeitenden Knotens komplizierter ist, also sich eine Auslagerung lohnt.
Danke!
flowdy
Last edited: 2012-11-08 14:17:34 +0100 (CET)
package MyClass; sub new {\b\b\b\b\b\b\b\b\buse Moose;