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

[P T Withington]

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