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

[P T Withington]

Well, a naive test of just removing the constraints and setting the  
corresponding init arg to null does not work.

So, I guess we would have to go with your suggestion that would allow  
'sophisticated' constructors to know when there is a constraint on an  
init arg.  The question is, I don't think this should be inserted as a  
`$constraint` init arg, but, I'm not sure I want to add another  
argument to `construct` either...

Going back to 4.0, it used to be that you could tell a constraint  
existed by looking at the $refs init arg.  AFAICT, only  
LzReplicationManager, LZView, LzTextSprite and LzInputTextSprite  
examine $refs to see if there is a constraint.  LzReplicationManager  
is trying to see if there is a constraint on datapath or xpath; the  
others are looking for constraints on width and height.  The sprites  
_really_ should not be looking at init args -- they ought to just take  
their cue from their generic owner.

Given those extremely limited cases, it seems we might be better off  
creating a private API for those kernel classes to learn about  
constraints, rather than burden the `construct` interface.

On 2008-11-24, at 16:08EST, P T Withington wrote:

> Man.  This is so messy.  It's like you plug one little leak and two  
> more spring up somewhere else.
>
> But, do View and Text _really_ need to know that?  They both allow  
> setting of width/height after the fact, which is what a constraint  
> will do.  It seems to me the examination of width/height in the  
> constructor is just a premature optimization that will get  
> overridden when the constraint is installed.
>
> On 2008-11-24, at 14:11EST, André Bargull wrote:
>
>> > 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.]
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>
>