Re: Enumerating Inherited Properties

["Peter Hill" <corwin@...>]

Wim Couwenberg:
> Both your example and that of R. Lake don't.  What's more, both these
> examples simply don't work! Shame on you guys!  ;-)

Whoops, you noticed even before I posted my new version. That was quick!


> A key that is defined in an "inheritance" chain hides all the same keys
> further up that chain.  Enumeration should respect this data hiding.

Hmm, I notice that my new version (which I actually bothered to test this
time!) happens to meet that condition, though I was not actively aiming for
it :-). Actually, since 'next' gives an error for keys that are invalid,
this is probably the only way to do it (it just took me a bit of thinking to
realise that).

As far as efficiency goes, the standard 'next' function relies on the
underlying object being fast-keyed. My revised 'tnext' method, while not
being especially efficient, is still quite acceptible because the underlying
structures are keyed tables.

But for non-fast-keyed data...


Peter Hill:
> If someone has a sample __index function I'll try to come up
> with an example matching __next.

Wim Couwenberg:
> It's common that such a function accepts indices from some finite list,
> but this list is not reperesented as the keys in a table, or even in Lua.
> Userdata do this a lot (store keys in an internal C array.)  Another
> example would be a generic object binding where the keys are not fixed but
> must be internally queried by some other specific method (COM for example,
> eeeek!)

Overall, I think having a __next metamethod seems worthwhile. BUT it would
also be nice if the 'for' statement would ALSO handle generator functions
(ie, ones with internal state) for those situations (especially involving
certain user data, eg file directory scanning) where an internal state is
required.

*cheers*
Peter Hill.