Re: tag methods question

["John Belmonte" <jvb@...>]

From: "Luiz Henrique de Figueiredo" <lhf@tecgraf.puc-rio.br>
> >Section 4.8 of the manual says that the tag method events are hard coded
> >into the interpreter.  Does this apply to the setglobal/getglobal events
> >even though they are defined in the basic library?
>
> No tag methods for setglobal/getglobal events are defined in the basic
library,
> which only contains setglobal/getglobal *functions*.

Sorry for the bad wording, I was referring to the "event functions" which
call the tag methods.  Although it's stated that they are part of the
interpreter, two of them (setglobal/getglobal) are also in the library.  I'm
assuming that these two just mirror what the interpreter does... or for
example does the interpreter actually call the library's setglobal when a
global assigment is made?

> >I'm trying to find a way to have global access routed to the normal
access
> >of the global table (not raw).
>
> That's what the setglobal/getglobal are for.
>
> You *might* give the global table a tag and then use the settable/gettable
> tag methods,

This doesn't seem to work.  If I give the global table a tag and use the
settable tag method, for example, the tag method doesn't get called when I
do a global assignment.  Did I misunderstand you?

> but keep in mind that the semantics of the two sets of tag methods
> is not the same.

I have to ask: why are the semantics different?  For globals the tag of the
old value is used for tag method lookup, and only tables and userdata are
supported.  For tables the tag of the table is used, and all types are
supported.  Now that the globals are in a normal table, what is the point of
having two sets of semantics?  In fact, since the table semantics are a
superset of the global semantics, they could be used to emulate the global
semantics in case that is still desired.

> Could you give us an example of what you want to?

I have a concrete (if not too useful) example that I'm working with.  It's
the "overloaded functions" extension that I had posted in April.  The
version that I first made worked only with functions in the global space,
and I had argued, "why do I have to write this extension two times- once for
globals, and again for tables?".  Now with 4.0 beta I have re-written the
extension for tables, thinking that since globals are now stored in a table,
I can use a single extension for both cases.  But it's not possible because
even though globals are now in a table, the semantics of the tag methods are
still treated like the old way.  (I've posted the new version on eGroups in
the files section-- "overloaded-2.lua".)

More generally, I'd like to use Lua's extension ability to do interesting
things like make a robust module system.  Not just the simple keeping
variables in a table, but a system that would allow control of what is
imported & exported, and allow renaming of imported names-- all without
interfering with other extensions.  Lua's extension system just needs a few
improvements to do this kind of thing reasonably and that's what I'd
outlined in my email "global environment special case" from April.

Best regards,
-John