Re: Tied hashes and arrays, yeah. But tied typeglobs?

[tilly]

You could give the $tho object a method that advances by one row. Then your sample usage is something like this..

my $tho = tie %th, 'My::DB::User', {-data=>\%nu};
while (exists $th{'username'}) {
  print "username is: $th{'username'}\n";
  $tho->nextRow;
}

If you want to consider more arbitrary APIs and tie is not doing what you want in terms of overloading behaviour, you can play games with overload instead.

However my suggestion is that your API will quickly become so arbitrary that would-be users will have a hard time figuring out how it could possibly do what it does under the cover, and will get very confused. Were I going from scratch, KISS tells me to seriously consider not setting any tie anywhere because I don't see how it is clarifying my API.

[Phaysis]

Thanks for the overload suggestion. I can see where I could use it, carefully of course, for autoincrementing or autodecrementing the current row.

I am, though, plowing ahead with a variation of what I suggested above. The My::DB::TIEHASH method tests for the need to load one row or many rows based on a few cases: if there's a "WHERE" clause defined in the parameter -where=>'active = 1' in the tie constructor (any "WHERE" existing assumes multiple rows), or if data passed in through -data has an array of hashes in it instead of a plain hash (many rows).

Right now, my sample code usage goes as follows:

...
tie %th, 'My::DB::User', {-where=>'active=1'};
for (my $i=0; $i < $th{'_ROWCOUNT_'}; $i++)
{   $th{'_CURRENTROW_'} = $i;
    print "$th{'username'} has been an active member since $th{'create
+d'}\n";
}

I do see a situation where overload could be useful, though. The whole for loop could be avoided by overloading ++ and -- to manipulate $th{'_CURRENTROW_'} like so:

...
while ($th{'_CURRENTROW_'} < $th{'_ROWCOUNT_'})
{   #do something, then:
    $th{'_CURRENTROW_'}++;
}

I should look into this. I may not need to overload depending on how autoincrement acts on the tied hash already ; I need to test this. As far as my API is concerned, I think it's working out rather well in this case. I can see where it can become a ball of mud, but I'm fighting to keep it simple. Of course, I've not gotten into making the variant subclasses of My::DB for all the remaining tables yet....