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

[André Bargull]

Would this work?
1) Extract all constraint from the "iargs"-object
2) Store all constraints as '$constraints', in case anybody needs to 
access them
3) call construct()
4) update constraints, in case user-construct() overrode an initial 
constraint


>     var constraints:Object = {};
>     for (var a:String in iargs) {
>         var arg:* = iargs[a];
>         if (arg is LzInitExpr) {
>             constraints[a] = arg;
>             delete iargs[a];
>         }
>     }
>     // save as a special attribute, so we can process
>     // constraints more efficient in __LZapplyArgs()
>     iargs['$constraints'] = constraints;
>     
>     this.construct(  parent , iargs );
>     
>     for (var a:String in constraints) {
>         if (a in iargs) {
>             // user construct() overrode constraint
>             delete constraints[a];
>         }
>     }



On 11/24/2008 7:23 PM, André Bargull wrote:
>> 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.]
>>
>
>