 |
lua-l archive |
|
|
||
|
On 16-Aug-05, at 1:12 PM, Chris Marrin wrote:
The one nice feature that Python has is: from math import *which imports all names from math into the namespace. I suppose that could be done with:import("math", "all") or something like that.
This cannot be done at compile time, since the compiler has no real way of knowing what might be in a package at run time. So it could not fabricate the necessary locals.
I personally can live without this feature, though. You end up with the local math, which you can use to access specific functions (math.log); if you wanted to reference them directly, you would need to import them explicitly, which is simply saying that locals need to be explicitly declared.
However, I'm a trifle uneasy about the 'local log = math.log' optimization, because it makes overriding package methods unreliable. Say, for example, that I have a reimplementation of string.find (as an example). If a package "imports" find from string, and it is loaded before I modify the string namespace, the package will use the base version; otherwise, it will use my "improved" version.
This may not strike anyone as an issue, but consider the case where I want to upgrade a package in a running program. I can (possibly) do that by changing the contents of the package table without changing its identity, but I cannot do it reliably if elements of the package table have been assigned to locals (which have presumably become closed upvalues).
It might be more interesting/useful to think about how to optimize the lookup of pkg.method, specifically in the common case where pkg is an upvalue and method is a constant string known at compile time. In the current VM implementation, the fact that pkg is an upvalue will force an additional vm op (GETUPVAL), in addition to the hash lookup of method.