[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: about the next version
- From: Edgar Toernig <froese@...>
- Date: Wed, 17 Apr 2002 16:02:51 +0200
Luiz Henrique de Figueiredo wrote:
>
> >I'm not sure if the global statement is the right thing.
>
> It's a new thing, and certainly not simple (or at least capable of being used
> in quite complicated ways), but we thing it does address a need. Or doesn't it?
> (The only snag right now is the need for "predeclarations".)
It does more. As I see it, people want some kind of protection against mistyped
variable names. One fundamental part of that is a way to easily know which
globals are exported by a module/file/library. That is not addressed with the
current global statement (the 'snag' you mention: the core wants to export
globals without the need to import each one individually).
> The "global" declaration is for sophisticated uses, but I don't think it makes
> the language more difficult: it just let's you do complicated scope control.
And that is what I fear. The simple 'global <name>' is easy and I have no
problem with that. A method to let the compiler check for undefined names.
But the 'global ... in <table>' is something completely different. It doesn't
address the mentioned 'need'. It introduces a method for complicated dynamic
variable bindings and my fear is that you get even more complex rules (Which
identifier accesses which object?) than the rules in C++. Reading sources
may become a nightmare.
In fact, I think that the 'global ... in <table>' has nothing to do with globals
any more. It's a shorthand to access table fields (Pascal's with-statement).
A completely different topic.
Maybe it would be better to add only the simple 'global <name>'. Then, for
Lua 6.0, think for some way to export globals to other files and add that.
My 2 cent, ET.