Hi, guys.
I think it would be good to bring this up with the authors. Being
able to follow the native restrictions is helpful for using Lua in
system scripting, and generally in line with Lua's scalable attitude.
The proposed alternative of making 'arg' a userdata which would proxy
to the operating system's strings sounds small code, efficient and in
every way preferable to me.
Maybe that should be made into a patch and proposed to the authors,
then?
There are some issues, though.
- If 'arg' is being phased out at some point (it no longer is needed
for anything, really) how to give the unlimited functionality to
'...' at the chunk level?
- If 'arg' remains, it could work "unlimited" whereas the '...' way
would carry the limits.
hmmm....
John Belmonte kirjoitti 22.12.2007 kello 5:45:
On Dec 21, 2007 3:47 PM, Norman Ramsey <[EMAIL PROTECTED]> wrote:
The patch (not setting '...') is easy and even discused on the
lua mailing
list, but is clearly a drift from the upstream I'd like not to
perform.
It would be a clear violation of the semantics as stated in the
reference manual.
I'm not suggesting we depart from upstream. This is an upstream
misdesign which they need to correct. If function/chunk arguments are
a constrained resource (like CPU registers, stack size, etc.) then the
lua interpreter has no business mapping command line arguments to
them. What if some OS had virtually unlimited command line length?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
