[Laszlo-dev] Proposal to revert behavior of LzNode.construct to 4.1 behavior

[André Bargull]

> 2)  It is possible some construct override manipulates init args expecting to affect how they will be processed by LzNode/__applyArgs (likely, but horrible, and deserves to break). 

Do you want to restrict the "args" argument of "construct()" to be 
read-only? Because that won't work, e.g. see LzView, LzText, LzCanvas, 
LzReplicationManager, ...




On 11/24/2008 6:57 PM, P T Withington wrote:
> I'm working on http://jira.openlaszlo.org/jira/browse/LPP-7378 and see 
> that there are many places where we have failed to check for an 'init 
> arg' having a non-constant initial value (it's value being an instance 
> of LzInitExpr).  This has led to any number of bugs, which have been 
> quashed by inserting /ad hoc/ checks throughout custom construct methods 
> (and may have even leaked out to components, possibly even user code).
> 
> In previous versions (prior to 4.1), non-constant initial values were 
> passed in a separate list, so LzNode/construct overrides never saw these 
> non-constant values.  I merged these (multiple) lists, so that the 
> overriding of init args would be correct in subclasses and instances 
> (this solved a number of bugs with trying to override a constraint with 
> a constant value or vice-versa, which was impossible to get correct when 
> the two were inherited by separate chains).
> 
> But, I think passing these non-constant values to LzNode/construct was a 
> mistake.  There is _nothing_ that a construct method can do with these 
> arguments, since they are internal to the LzNode protocol.  Since these 
> overrides never saw these values in the past, I don't believe anything 
> can break by removing them from the arguments passed to construct.
> 
> PROPOSAL:  The argument list to LzNode/construct will be a _copy_ of the 
> 'init args' passed to the constructor, with all non-constant arguments 
> removed.
> 
> PRO:
> 
> 1)  Backward compatible
> 2)  Obviates exposing internal API's
> 3)  Simplifies processing of init args in LzNode/construct overrides.
> 
> CON:
> 
> 1)  It is possible some construct override depends on knowing that an 
> argument will be constrained (unlikely)
> 2)  It is possible some construct override manipulates init args 
> expecting to affect how they will be processed by LzNode/__applyArgs 
> (likely, but horrible, and deserves to break).
> 
> Comments?
> 
> [Filed as http://jira.openlaszlo.org/jira/browse/LPP-7386, Please enter 
> your comments there.]
>