2012-11-08T12:49:53 flowdy

[...]
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;
}

[...]

Hmm, also ich finde es nicht sehr intuitiv, wenn eine Iterationsmethode standardmäßig die Iteration sofort abbricht und mit einem Callbackaufruf zur Fortsetzung ihrer Arbeit bewegt werden muss. Abgesehen davon ist die Exceptionbehandlung nicht unbedingt besonders schnell und könnte die Schleife ausbremsen, wenn sie in jedem Schritt durchlaufen wird.

Quote

[...]
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
[...]

Einen Iterator zurückzugeben ist auch nicht dumm.

Ein Grund so eine Schnittstelle bereitzustellen selbst wenn eine explizite Schleife nicht schwieriger zu verwenden ist, könnte die Normalisierung der Schnittstelle über verschiedene Containertypen hinweg sein.