I think that you should be able to make it a static class, since `id`
is defined as being "tag only, and final" which means that it cannot
be set at run time (even though that is how it is presently
implemented). I would hope that by making it a static class, the JS2
compiler can completely optimize away the dynamic lookup that the
`with` would otherwise imply.
BUT: there is one other "gotcha" I forgot to mention as to why you
can't "wrap every function's contents with 'with (global)'". Consider
the following:
global.foo = '42';
class bar {
static var foo = 13'
var foo = 7;
function zot ():Function {
var foo = -3;
return function () { return foo; }
}
}
((new bar).zot())() => ?
Should yield `-3`, but if you take the simple approach of wrapping
`with (global)`, will yield `42`. (And similarly for the instance and
class `foo` if the closer binding were not present.)
The compiler already also can tell you about closed-over variables,
so, I think the best solution is to simply rewrite free references (to
global.foo) when they match declared id's (which the tag compiler can
tell the script compiler in advance, because it is going to put them
in a static class with a singleton instance). The one additional
piece of analysis that is needed is to find the instance (including
inherited) and class variables that could match the free reference --
those should not be rewritten, but I'm not sure the compiler takes
those into account when doing its analysis.
On 2008-02-09, at 13:52 EST, Henry Minsky wrote:
OK I'd like to try doing this. I wonder if I should make a static
class named 'global', as opposed to just an Object bound to a global
var. That way the compiler could declare all the id's that are known
at compile time as 'fixtures', and presumably new
properties could be added at runtime when needed.
On Sat, Feb 9, 2008 at 1:07 PM, P T Withington <[EMAIL PROTECTED]> wrote:
I only suggest the conditional wrapping for performance reasons...
'with' does not come for free. And the compiler is already doing the
necessary analysis.
On Feb 9, 2008, at 10:15, Donald Anderson <[EMAIL PROTECTED]> wrote:
Why not wrap every function's contents with 'with (global)' ?
And can user code do this with top level vars?
var blah = globalvar;
That would need to be fully qualified (either by smart compiler or
user).
On Feb 9, 2008, at 7:32 AM, P T Withington wrote:
This is probably the right time to bite the bullet and stop using
the global namespace. It has already cause problems with name
collisions. Per my comment, "global" should probably only mean "in
this canvas's scope". So, yes create an object that holds these
global names. Heck, you could even call it `global`... :)
Our compiler already analyzes each method to determine if there are
free references in the method. We could use this analysis to
insert a `with (global)` block around any such code, so that no
user code would have to change.
On 2008-02-08, at 23:31 EST, Henry Minsky wrote:
In DHTML and AS2, we get away with doing this for setting node
id's to
be global vars:
function setID ( id ){
//support for current system
if ((typeof(id) == 'string') && id.length) {
if ($debug) {
if (global[id] && global[id] !== this) {
Debug.warn('Redefining #%s from %w to %w',
id, global[id], this);
}
}
this.id = id;
// TODO: [2006-03-22 ptw] Should id's really go in the
user/canvas module?
global[ id ] = this;
} else {
if ($debug) {
// id is permitted to be null or undefined, meaning
// "don't id me"
if (id) {
Debug.error('Invalid id %w for %w', id, this);
}
}
}
//namespace system
//app[ id ] = this;
//local reference
}
This works because we aliased "global" to _root in AS2, and to
"window" in DHTML.
I don't see any way to do this in AS3. There doesn't seem to be
any
magic object whose properties
become global vars. I'm not even sure how to get the runtime to
set
global id variables by name procedurally during
instantiation even if we declare them. I hacked the tag
compiler to
emit a list of top level var declarations for all id's, but
I don't see how to emit the code for the instantiator to bind to
them
when the nodes are created, because what can you put on the
left side of the assignment?
One solution would be to make an API change, and require all
globally
named nodes to be referenced via some object
like "lz", which we already are kind of pushing for class names.
Tons
of user code would have to be updated.
To add one more twist of the knife, for the debugger eval
mechanism,
if we want to use globals, we need to have a list of them
someplace to compile in to the little debugger stub template app,
because that code is compiled independent of the application code.
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
--
Don Anderson
Java/C/C++, Berkeley DB, systems consultant
voice: 617-547-7881
email: [EMAIL PROTECTED]
www: http://www.ddanderson.com
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
