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

Henry Minsky hminsky at laszlosystems.com
Mon Nov 24 10:05:16 PST 2008


It seems like a good thing to do.  It seems like it is worth fixing any code
that depends on seeing constraint functions in theconstruct method.



On Mon, Nov 24, 2008 at 12:57 PM, P T Withington <ptw at pobox.com> 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.]
>



-- 
Henry Minsky
Software Architect
hminsky at laszlosystems.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20081124/c91dd416/attachment.html


More information about the Laszlo-dev mailing list