Re^8: Getting for() to accept a tied array in one statement

I believe (or at least this is how I understand it) that the point of the exercise is SoC. The 'wrapper' causes a separate function to execute every time an element inside of the array is accessed and this function is defined somewhere else (not inside the while loop). Your code could work in case it would have used a reference array instead. But I think you mean with 'expensive' you mean using the tie?

Anyways, if you would use an array reference your code does work:

use lib '.' ;
use strict ;
use warnings ;
use ar ;
my @ar ;
my $ar2 = tie @ar, "ar" ;
@ar = (1, 2, 3) ;

sub make_list_iterator {
   my $list = $_[0] ;
   return sub {
      return () if !@{$list};
      return shift(@{$list});
   };
}

my $iter = make_list_iterator(\@ar) ;
while ( my ($item) = $iter->() ) {
   print "$item\n" ;
}
[download]

I'm not showing how to implement ar, plenty of examples in previous posts

Comment on Re^8: Getting for() to accept a tied array in one statement Select or Download Code

Replies are listed 'Best First'.
Re^9: Getting for() to accept a tied array in one statement by ikegami (Patriarch) on Apr 19, 2019 at 17:59 UTC
Why????? The code I posted already worked as-is. No need to create a tied array and the underlying class. My code already calls a sub for each element.	[reply]
Re^10: Getting for() to accept a tied array in one statement by Veltro (Hermit) on Apr 20, 2019 at 09:45 UTC
I'm not saying that your method is incorrect. I am just looking at a different form of abstraction. In the case of using the Iterator, where does it resides? I assume that is in the collection class. Then the Algorithm and the Iterator are combined into one. But then I think, this is not right. The sole purpose of an Iterator should be traversing (up, down) through the elements of the collection. Then algorithms can be defined that take iterators as an input arguments. Also I feel that Iterators should be objects themselves and contain begin and end methods (maybe even overloading ++ and --) CollectionX ->begin (Iterator) CollectionY ->begin (Iterator) CollectionZ ->begin (Iterator) ->end (Iterator) ProgressBar Flowers Algorithms - showProgress - Bound to ProgressBar - growFlowers - Bound to Flowers code: ... use CollectionX ; use CollectionY ; use Algorithms qw( showProgress, growFlowers ) ; ... my colX = new CollectionX ; colX->... ; while( showProgress(CollectionX->begin) ) { } my colY = CollectionY ; colY->... ; while( showProgress(colY->begin) ) { } my colY = CollectionY ; colY->... ; while( growFlowers(colY->begin) ) { } [download] With this level of abstraction it is only needed to define iterators for each type of collection, and only one algorithm for each added functionality. Otherwise I would need to create an iterator for each added functionality for each class (in this example 6 iterators instead of 3) and repeat code 3 + 3 times. I'm not going to build examples on this, just too much work right now. But I think the method with the `tie` shown by hdb makes this possible and that is why I said like it so much. I hope this helped understanding where I am coming from.	[reply] [d/l] [select]
Re^11: Getting for() to accept a tied array in one statement by ikegami (Patriarch) on Apr 20, 2019 at 12:32 UTC
The sole purpose of an Iterator should be traversing (up, down) through the elements of the collection. But that's what the OP wants, assuming the code the OP wants to execute for each element specifically fetches or generates the element to be returned. If that's not what the OP wants, there's no point to their wrapper, so there's no point to a tied array or iterator. They should simply place the logic in the loop itself. The rest of your post makes no sense. You only need three implementations with an iterator if you have three implementations with a tied array since the tied array approach is literally being used as an iterator (a role it is badly equipped to handle). The tied array is pure needles complexity and overhead, the very thing programmers should be avoiding. It adds absolutely no value. Tied arrays are a hack that should only be used to shoehorn logic into existing bad code. The very idea of a tied variable (to make code look like variable) is a bad practice. They should be used as a last resort. They should definitely be avoided when they are costly and don't provide any benefits like in this case.	[reply]