Here is a more concise proposal:
The `id` property of a node will only cause a global binding in LZX.
To achieve the same effect in JS, you must make the binding yourself:
var <idname> = new <node subclass>(<parent>, {id: <idname>, ...});
The `name` property of a node will only cause a global binding in LZX
if that node is a lexical (not placed) child of the canvas.
I have implemented these changes, and lztest and smokecheck pass.
Still sorting runlzunit. Seems like <command> is doing something
funky with id's...
On 2008-04-10, at 06:09 EDT, P T Withington wrote:
On 2008-04-10, at 03:28 EDT, André Bargull wrote:
`lzAddLocalData` is _not_ used for local datasets, it is used for
top-level datasets, see "DataCompiler.java". So that's a compile
time issue, which shouldn't be a problem even in swf9.
So just a convention, which we could change, and still be
transparent to the LZX user.
I've observed in the past that datasets seem to get defined in 3
places: globally, on the canvas, and in canvas.datasets. This would
seem like overkill. Perhaps we could limit them to being defined in
just two places, or maybe even one?
These two constructs no longer work to create a global object:
new <lznode subclass>(canvas, {name: 'foo'});
new <lznode subclass>(canvas, {id: 'foo'});
That's what I am proposing. The replacement would be:
[At the top level of your program]
var foo;
[Anywhere else in your program where `foo` is lexically apparent]
foo = new <lznode subclass>(canvas, ...);
This is not a full replacement, since the foo object will not know
what global it had been bound to.
Hm, would it make sense to integrate "as3 global-support" like this
"http://www.uza.lt/codex/as3-global-object/";? That way you can
create code which works in all runtimes,
provided that everyone uses "global.foo" to access a global object.
We already have that in a sense. Any top-level object will be a
child of the canvas, so named objects on the canvas are always
accessible as `canvas.<name>`. We could say that an object with an
id similarly becomes accessible through the canvas as `canvas.<id>`.
The plus of going this way is there would be no collisions with
runtime globals. The minus would be that everyone would need to be
re-trained to qualify their free references. That would probably
not be acceptable...
What I am proposing is just a restriction on JS dynamic creation of
nodes. At the LZX level, we already state that node `name` and `id`
properties are final. I'm proposing a restriction that at the JS
level, they are not properties of node at all; that if you want your
node to be a global value or a property, you do it yourself.
On 4/10/2008 2:11 AM, P T Withington wrote:
Because I can't see how to implement that at runtime in swf9.
Currently, if I say:
new <lznode subclass>(canvas, {name: foo});
the global `foo` will be bound to my instance. In particular,
this idiom is currently used by `lzAddLocalData` and
`lzpreloader`. Do local datasets really need to be stored as
globals? This seems like namespace pollution to me. We can't do
this in swf9 because swf9 does not let you dynamically add global
names.
I would like to remove support for a top-level name acting as an
id. In fact, our documentation says that both `name` and `id` are
final, which would indicate to me that you should not be able to
supply them at run time at all. IWBRN to remove this wart.
