[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Type Metatables for Table and Userdata - Powerpatch
- From: Wolfgang Pupp <wolfgang.pupp@...>
- Date: Fri, 7 Dec 2012 00:56:17 +0100
Andrew Starks wrote:
> In the same way, making "for k, v in t do..." has the same problem. In the
> name of a more "natural" syntax, to my thinking, you've obfuscated the fact
> that a function that returns a function that knows how to iterate "t" is
> being called.
Let me rephrase/clarify: What I argue for is to *extend* Luas generic
for syntax (currently "iterator function syntax") into an "iterator
function OR table iteration"- syntax.
It'd be like giving the language a concept of "traversing a table". By
default, this traversal would behave like pairs (the *only* sensible
choice). But in some (rare!) cases, one might wish to override that
default behavior (via __iter) i.e. when the table contains no real
data because it serves only as an abstraction.
Both table iteration overriding and "raw" traversal would still happen
via conventional iterator functions.
Points in favour:
- table traversal is a simpler concept than iterator functions-
(partial) separation would be beneficial at the very least for
beginners.
- pairs needs to be a "magical" function anyway (can't be implemented
without "cheating"), and it basically *never* appears outside of the
for-statement (it is never needed "as function"- only for what it
achieves inside a for-loop).
The fact that an iterator function might be called for the "table
iteration" syntax is an implementation detail, not an obfuscation.
> I like the idea of writing explicit iterators, rather than
> redefining ipairs/pairs, but I'm probably in the minority on that one)
I strongly agree with you on this. The meaning of iteration (be it via
__pairs or __iter) should only be overridden IMO when the new behavior
is absolutely the *only* one that makes sense. Being explicit never
hurts; but having to call "pairs" for every table traversal is
*boilerplate* code IMHO, not being explicit.
Sven Olsen wrote:
> Unfortunately, it ("for k,v in t do ..." syntax) simultaneously obscures the function of the code.
I do not understand what you mean- could you elaborate on this?
--Wolfgang