Re: adventures with iterators

[Sven Olsen <sven2718@...>]

Here's a fairly conventional solution, but packaged conveniently:

I do love proxy tables.  But I've been thinking more about this, and I've realized that the essential problem isn't actually that my tables already have __newindex methods.  It's what I'm using said __newindex methods for.

Briefly -- the tables in question are themselves proxies, and their metamethods are being used to maintain a list of changes written to an underlying state.  This means that any iterator tricks that postpone the moment when changes are actually committed are probably a bad idea.  Not because of any technical issues -- but because they're likely to confuse the programmer (me), into thinking that certain changes have been added to the list before this is actually true.

One of the nice things about your proxy approach is that it would force me to acknowledge the complexities of a delayed write immediately -- the access wrapper is explicit, as is the call to commit the changes.  With a modified version of Dirk's xpairs, I'd probably end up writing subtle and complex bugs.  But with your proxy approach, I'd be forced to refactor a lot of my code in such a way that those kinds of bugs would be far less likely to be written in the first place.

Either way though, in my own use case, any form of delayed writing is almost certain to be a case study in the evils of premature optimization.  I have small table sizes, and plenty of spare CPU cycles and memory, so sticking with something conceptually simple, if theoretically inefficient, is almost certain to be my best bet.

Thanks for the detailed reply though :)

-Sven