[Laszlo-dev] Do we really need top-level name => id idiom?

[P T Withington]

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.
>>