[Laszlo-dev] Initialization difference between swf and dhtml

[Henry Minsky]

Hey I just tried moving that new LzDelegate out of the loop and it
didn't break centering
of text in the button component. I wonder if we fixed that when we
fixed the order of setters or something.

I think we should bite the bullet and normalize the order of
everything, otherwise we'll
be like those guys at Microsoft, crushed under the weight of backward
compatibility
with every version since Windows 3.1 or something.


On 11/28/06, P T Withington <ptw at openlaszlo.org> wrote:
> 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
> >
>
>


-- 
Henry Minsky
Software Architect
hminsky at laszlosystems.com