[Laszlo-dev] Construct methods and attribute predicates [Was: Didn't you report a bug about _instanceAttrs and states?]

[André Bargull]

On 1/11/2009 4:21 PM, P T Withington wrote:
> [Adding laszlo-dev]
> 
> On 2009-01-11, at 07:17EST, André Bargull wrote:
> 
>> On 1/11/2009 12:12 AM, P T Withington wrote:
>>> Henry and I are floundering trying to fix LPP-7602 and I think the 
>>> reason my idea doesn't work is that if there is a constraint in a 
>>> class, it does not show up in _instanceAttrs, so it won't be removed 
>>> by a state.
>>
>> Yes, only _instanceAttrs will be removed by states. But nevertheless, 
>> I'd like to remind you on this email conversion on laszlo-dev: 
>> "http://www.openlaszlo.org/pipermail/laszlo-dev/2008-March/013658.html".
>> My last mail is still unanswered, it points out to an example in the 
>> doc where a constraint used to be re-enabled (but not executed!) [1] 
>> after a state was removed.
> 
> I seem to have dropped the ball there.
> 
> But, I am not comfortable with applying a constraint and not executing 
> it.  That seems like a ticking bomb.  If a constraint is applied, it 
> should be enforced, no?

It rather depends [1] on the terms you use to describe what happens:
- if you say you remove and later reapply the constraint, it sounds like 
the constraint should be re-executed
- but if you say you disable and later re-enable the constraint, you get 
a more loose description which doesn't imply re-execution (at least in 
my opinion)


[1] In this part of the conversation, an example was outlined which is 
more or less the opposite of the intended behaviour of debugger-window:
"http://www.openlaszlo.org/pipermail/laszlo-dev/2008-February/013289.html"



>>> Actually, now that I think of it, maybe the bug had to do with 
>>> replication?  But I think it is the same issue...
>>
>> Maybe you had LPP-7420 in mind? For the bugfix, I've added 
>> "__LZgetInstanceAttr" to LzReplicationManager, this methods tries to 
>> look up an attribute in the "_instanceAttrs" and if the attribute 
>> wasn't found, it tries next "node['constructor'].attributes".
> 
> Yes.
> 
> It seems like we need a general mechanism in the constructor to ask:
> 
> 1) Is there an initial value for this attribute (whether from class or 
> instance, whether constant or constraint)

In "construct()", you just get the merged list of instance attributes 
and attributes inherited from class. The only thing you don't get are 
constraints. So you want to make "__LZhasConstraint" a public API, 
although you had the opposition position a couple of weeks ago? (Just 
want to point out that we shouldn't let us influence by things that 
easily ;) )


> 2) Is there a constant initial value for this attribute (whether from 
> class or instance)

The "args"-object consists solely of constant values (from both instance 
and class), doesn't it?


> 3) Finally, as Henry has suggested, if an attribute is constrained, 
> shouldn't setAttribute remove that constraint?  Is this the general 
> mechanism that should be used to remove constraints?

I don't think so. "that.setAttribute('foo', ...)" is just a way to 
workaround the fact that we don't have real JS2 setters in all runtimes. 
So in the future, we just like to have "that.foo = ..." to call the 
defined setter for the "foo"-attribute.
So if you add more and more complex code to "setAttribute":
1) you won't be able to get the easy transition to JS2 setters
2) and you also need to consider that "setAttribute" is inlined, so more 
code results in bigger applications

There are likely even more aspects which make clear that setAttribute 
isn't a good candidate for such stuff.