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

[P T Withington]

Ok, I updated the change, if you would like to re-review it.  Your  
test case now works (not in swf9, but it didn't before -- I'm filing a  
bug).

You convinced me that it is better to just pass the constant init args  
to the constructor.  The constructor should not be worrying about  
constraints in general.  If an attribute is constrainable, it will  
either have a setter or the default setter will work, but that has to  
work independent of any initial value.  The most constructor overrides  
should do is handle constant initial values (as an optimization), or  
enforce that an attribute is 'final' by handling it only in the  
constructor (and using a custom setter that signals an error).

construct overrides should _not_ add to the init args list, since they  
can't (without using a private API) know if there is a constraint they  
would end up hiding.  Perhaps a future improvement is to only pass a  
copy of init args to the construct method; but I'm not ready to try  
that now.

On 2008-12-01, at 19:03EST, André Bargull wrote:
> 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. :-)

True.

> 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`.)

See above.  I think the _only_ thing a construct method should be  
allowed to do is to delete an init arg if it has handled it, but there  
are some legacy classes that smash things into init args.

> 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?

It does not know the setters for the LFC classes.

> 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) ;-)

Now there is a new candidate:  ^.  It is an amusing conversation.