[Laszlo-dev] For Review: Change 20081130-ptw-v Summary: Revert init arg behavior

[André Bargull]

On 12/1/2008 9:11 PM, P T Withington wrote:
> On 2008-12-01, at 14:41EST, André Bargull wrote:
> 
>> The behaviour doesn't really match 4.0, because the "iargs" are set to 
>> `null`, so if a user asks for "'foo' in args", it was `false` in 4.0, 
>> but now it's still `true` (if 'foo' is a constraint). What about 
>> "deleting" the values from "iargs"?
> 
> Good point.  I was thinking that I should keep at least a null value in 
> iargs to indicate that the instance had _some_ binding of the argument.  
> I used null to be parallel to the case where there is an initial 
> argument for a slot with a setter:  right now LzNode sets the slot to 
> null when the instance is created (rather than leaving it undefined).  
> This seemed to be necessary for some setters to work.

It could only be a problem if any construct-method (now or in the 
future) needs to distinguish between `null` as initial value, or `null` 
as a marker for binding. But see below, I don't know any decisive 
arguments (yet) for (or against) the one or the other approach..


> 
> I'd like to get away from having to always ask `a in b` and use `b['a'] 
> != null` instead.  The `a in b` has caused us trouble in cases where b 
> is not dynamic or a is not a public attribute.  Do you think it is 
> really important to go all the way back an not list the argument at all 
> if there is a constraint on it?

I wonder if this a valid argument here, because the iargs need to be a 
hashtable, so it's both dynamic and all slots are public. :-)

I just wanted to be cautious and reduce possible bad user experiences, 
for instance if a user wants to remove a constraint which is supplied in 
the iargs-object, and if he sets the entry to `null`, nothing happens, 
but if he sets the entry to `undefined` (or any other value), the 
constraint won't be installed. (Yes, I have to admit the example is 
hypothetical, the user should use `delete`.)

There are pros and cons for both approaches, so maybe it's up to 
personal preference what to do...


btw:
> // Install any class decls that the tag compiler could't
> // figure out (because it does not know the built-in class
> // setters, c.f., ClassCompiler.java)

Still true? Doesn't the compiler know all setters now at compiler-time?


btw (2):
I also slightly lean toward the Haskell-like syntax for lambda 
expressions, looks more natural in code. (Haskell-like only because of 
the backslash) ;-)


>>
>> On 12/1/2008 5:55 PM, P T Withington wrote:
>>> Change 20081130-ptw-v by ptw at dueling-banjos.home on 2008-11-30 
>>> 12:01:16 EST
>>>    in /Users/ptw/OpenLaszlo/trunk
>>>    for http://svn.openlaszlo.org/openlaszlo/trunk
>>>
>>> Summary: Revert init arg behavior
>>>
>>> Bugs Fixed:
>>> Lpp-7378 LzTextSprite.setPattern warning in Laszlo 4.1.1, not in 4.0.12
>>> LPP-7386 Proposal to revert behavior of LzNode.construct to 4.1 behavior
>>>
>>> Technical Reviewer: a.bargull at intensis.de (pending)
>>> QA Reviewer: max (pending)
>>>
>>> Details:
>>>    Added a new internal API LzNode/__LZhasConstraint, which can be
>>>    used in LzNode/construct to determine if an attribute will be
>>>    constrained by LzNode/__LZapplyArgs.  This replaces testing for
>>>    LzInitExpr's in construct's arglist.  LzNode/construct' initargs
>>>    are now as they were in 4.1 -- only constant initial values appear
>>>    in that list.  Currently only LzText (and subclasses) use the
>>>    __LZhasConstraint API, because they (apparently) need to know of
>>>    their width/height will be constrained at construct time.  No
>>>    other LFC classes or component classes use this facility, so I
>>>    have kept is as an LFC private API.
>>>
>>>    LzTextSprite, LzInputTextSprite: These two sprite classes should
>>>    not be using the __LZhasConstraint API, but they are probably
>>>    going to be obsolete soon, so I just fixed them in the most
>>>    expedient way.
>>>
>>>    LzNode: Remove LzInitExprs from init args when calling construct,
>>>    while preserving the ability of construct replacing/adding init
>>>    args.
>>>
>>>    LzText:  Use new __LZhasConstraint API.
>>>
>>>    LzText, LzInputText, LaszloView: Simplify construct method, now
>>>    that args only contains constant values.
>>>
>>>    LzReplicationManager: Clarifying comment
>>>
>>>    hintedlayout: Fix construct arg defaulting bug noted in passing
>>>    (similar to LPP-7376)
>>>
>>> Tests:
>>>    smokecheck, ant test, test case from LPP-7386
>>>
>>> Files:
>>> M      WEB-INF/lps/lfc/kernel/swf/LzTextSprite.as
>>> M      WEB-INF/lps/lfc/kernel/swf/LzInputTextSprite.as
>>> M      WEB-INF/lps/lfc/kernel/swf9/LzTextSprite.as
>>> M      WEB-INF/lps/lfc/core/LzNode.lzs
>>> M      WEB-INF/lps/lfc/views/LzInputText.lzs
>>> M      WEB-INF/lps/lfc/views/LzText.lzs
>>> M      WEB-INF/lps/lfc/views/LaszloView.lzs
>>> M      WEB-INF/lps/lfc/data/LzReplicationManager.lzs
>>> M      demos/lzpixmobile/lib/hintedlayout.lzx
>>>
>>> Changeset: 
>>> http://svn.openlaszlo.org/openlaszlo/patches/20081130-ptw-v.tar
>>>
> 
>