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

[André Bargull]

 > I don't really want to expose the constraints mechanism to user code.
 > Do you know of any user code that would need to know about constraints?

At least LzView and LzText need to know whether any value was assigned 
for "width" resp. "height".


On 11/24/2008 7:49 PM, P T Withington wrote:
> I was thinking about this:
> 
> 1) Make a copy of all the constant args
> 2) Call construct on the copy
> 3) Copy any modifications (new or different) back to the original arg list
> 
> That would let construct overrides insert/delete args.  I don't _think_ 
> they should be inserting args, but they surely might delete args that 
> are 'fully processed' by the construct method.  [This would be how a 
> class could implement a 'final' attribute:  process the argument in the 
> construct method, remove the argument from init args, and define a 
> setter that does nothing (optionally signals an error in debug mode).]
> 
> I don't really want to expose the constraints mechanism to user code.  
> Do you know of any user code that would need to know about constraints?
> 
> On 2008-11-24, at 13:36EST, André Bargull wrote:
> 
>> 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.]
>>>>
>>>
>>>
>>
>>
> 
>