[Laszlo-dev] Initialization difference between swf and dhtml

[P T Withington]

You are 100% right Jim, but this will break a lot of apps that, right  
now, happen to 'just work'.  Please see the note at line 1124 in  
LzNode.lzs for a glimpse into what is at stake here.

I am all for making this change, but there will be fallout...  OTOH,  
if we _don't_ have to preserve the accidental behavior of  
constraints, we open up a whole raft of optimization possibilities  
that have been precluded by the requirement of backward compatibility.

On 2006-11-28, at 20:31 EST, Jim Grandy wrote:

> Agreed, but constraint satisfaction is too complex to enforce  
> lexical ordering over. It's also too hard to understand what's  
> going on if the two aren't in separate phases -- this is the  
> mistake in the current system, which leads to lots of constraint  
> satisfaction over uninitialized attributes. Plus in theory no  
> predefined order is necessary for constraints -- you just start  
> with one and keep going until it all settles down. I think this  
> would be clean:
>
> - initialize own class' attributes to constants, first by class and  
> then by lexical order
> - initialize instance's unique attribute to constants, in lexical  
> order
> - run all all attribute constraints, in undefined order
>
> jim
>
> On Nov 28, 2006, at 3:39 PM, Henry Minsky wrote:
>
>> Note that implementing the lexical ordering is likely to break a
>> couple of legacy apps
>> that depend implicitly on the current ordering. Of course, several
>> DHTML versions are
>> already broken due to the different order now (I think I fudged a
>> couple of constraints in the amazon app to work around one case
>> already, with height initialization on a component) , so it's not
>> really a reason to try to preserve existing behavior.
>>
>>
>>
>> On 11/28/06, Jim Grandy <jgrandy at openlaszlo.org> wrote:
>>>
>>> On Nov 28, 2006, at 2:33 PM, Adam Wolff wrote:
>>>
>>> > On Nov 28, Don Hopkins wrote:
>>> > [snip]
>>> >> I think it's pretty important to give class programmers the
>>> >> ability to
>>> >> control the order in which the attributes are initialized at  
>>> class
>>> >> declaration time.  It's also sometimes useful for object users to
>>> >> control the initialization order at object instantiation time,  
>>> but
>>> >> usually they shouldn't have to care, or be required to  
>>> understand the
>>> >> inner workings.
>>> > Agree that this is appealing and sensible, but I don't think it's
>>> > practically possible. As a class user, I can say
>>> >
>>> >     <yourclass attr1="$once{ a }" attr2="$immediately{ b }"/>
>>> >
>>> > and then attr2 will be set before attr1 regardless of what you
>>> > might want
>>> > as the class implementor.
>>> >
>>> > A
>>>
>>> I think constraint satisfaction has to be a separate phase from
>>> attribute initialization, and really needs to have indeterminate
>>> execution order to preserve optimization/implementation flexibility.
>>> Attribute initialization to a constant value really needs lexical
>>> order, by class. The two shoud really be separate.
>>>
>>> jim
>>>
>>>
>>
>>
>> -- 
>> Henry Minsky
>> Software Architect
>> hminsky at laszlosystems.com
>