[Laszlo-dev] Is this the idiom people use to set the initial value of an attribute in a class declaration?

[P T Withington]

Er, not.

All our attributes are instance attributes.  If you leave out $once,  
you get a micro-optimization if the initial value is a constant, and  
you get something you probably did not want otherwise.

It's a weak spot in the implementation right now that Henry and I  
hope to repair as we modernize the tag compiler.

On 2007-07-09, at 09:12 EDT, Elliot Winard wrote:

> I always assumed that, unless $once{} was used, I was declaring a  
> static attribute.  I thought that was noted in the docs.
>
> Maybe not?
> -e
>
>
> On Mon, Jul 9, 2007 at  7:55 AM, P T Withington wrote:
>
>> The bug we have is that we don't treat every instance initializer  
>> as an expression, so you can't say `value="new Array"` to get  
>> around the sharing, you have to say `value="${new Array}"`.  I  
>> think this is an FAQ that Antun covers.
>>
>> And yes, you are right.  This would be solved by moving attribute  
>> initializers into the class initializer.
>>
>> But if we fix this bug, we'll need to provide a way to share in  
>> the cases where you _do_ want to share, perhaps by providing an  
>> LZX way to declare a static attribute?
>>
>> On 2007-07-08, at 22:25 EDT, Henry Minsky wrote:
>>
>>> I've been hacking on an app this week, and realizing it's been  
>>> awhile since
>>> I tried
>>> to actually program anything in Laszlo.
>>>
>>> There's this huge "gotcha" when setting the initial value of  
>>> attributes to
>>> an object in a class
>>> declaration, like this
>>>
>>>
>>> <class name="foo">
>>>  <attribute name="pets" value="[]"/>
>>>
>>> Which screws you since that object will now be shared among all  
>>> instances.
>>>
>>> The idiom I think I remember people using is
>>>
>>> <class name="foo">
>>>  <attribute name="pets" value="$once{[]}"/>
>>>
>>> Or more readably
>>>
>>> <class name="foo">
>>>  <attribute name="pets" value="$once{new Array()}"/>
>>>
>>> Is that what we recommend to do now? I guess we going to quietly   
>>> fix this
>>> issue if and when we get
>>> our node initialization rewritten as a compile-time-generated  
>>> initializer
>>> function?
>>>
>>>
>>> -- 
>>> Henry Minsky
>>> Software Architect
>>> hminsky at laszlosystems.com
>
>
> ---=---===-------
> Elliot Winard
> Sr. Software Engineer
> Webtop Team
> ---=---===-------