[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Global access control
- From: Fred Bertsch <fb@...>
- Date: Mon, 29 Dec 1997 13:10:52 -0500 (EST)
On Mon, 29 Dec 1997 firstname.lastname@example.org wrote:
> > excellent point! and one of the reasons why we don't want to change anything
> > right now. specially since lua already provides tools (metamechanisms!) for
> > handling this. (of course, such tools are available at run time only.)
> I have thigs setup to allow access to function. I have a version that
> prevents assignment to functions unless they are declared in the global
This seems like a good solution to me. It is, of course, fairly rare that
you would want to perform assignment on a function. However, there are
cases where it can be very useful, and care should be taken to make sure
that these cases aren't any more difficult than before.
For example, you might want to create a new function with the name given
by a string argument to a function. While I haven't looked into the
optimal way to do something like this, I would assume it would involve
do_string. Is it safe to assume that the string evaluated from do_string
is executed from the global scope, and, therefore, can safely assign to
any global, including functions? Because of the increased differences
between global and local behavior, it becomes more necessary to carefully
define these things. (Though there are still differences now, so I assume
it's defined somewhere.)
> 1. Lua can't modify enough tag methods to really fix things (ie. you can't
> control plain table access), so have a really hacked up language when
> you're done.
This does seem to be true. I haven't come up with a satisfactory answer
to this problem by defining tag methods.
> 2. Runtime is just too late to detect these errors in a
> server environment or other robust system, especially since no overhead is
> added to Lua to do it at compile time.
> 3. You're adding runtime overhead.
These are worth worrying about. While it is possible to have a robust
system in some client/server environments with occational messy errors to
deal with, it is far, far better to not have to worry about it. After
all, the whole point of this discussion is to avoid having to be perfect
all the time. :)
The runtime overhead of a comprehensive set of tag methods would be
enormous, I suspect. Simple alternatives such as Russ's $global/$noglobal
syntax are better, simpler, and faster.
> If no standard is adopted, I'll probably continue to modify the Lex code
> and make my own version (though keeping up with new Lua releases will be
> a pain). I'd be glad to post my Lua source files as a optional
> non-standard solution, if that's allowed (is it?).
At the very least, perhaps you could post the modifications you had to
make to the source code, if not the actual source.
It looks as though the designers of Lua are thinking seriously about this
issue, and I'm very grateful to them for that! Thanks!