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

[P T Withington]

On 2009-01-11, at 11:11EST, André Bargull wrote:

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

I guess this depends on whether you want the "theoretical computer  
science" definition of constraint (essentially an assertion that is  
made true) or the current weak approximation to that which our  
constraint system embodies (relying on change events to trigger  
updates and never recursing).

My opinion is that if a constraint is applied the system should make  
it true.  (And that if that does not happen, it is a bug in the  
constraint system).  If you want something weaker than that, you  
should use event handlers, which let you react to just changes.

> [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 
> "
>>

Yeah, that example mystified me, because it was inconsistent with what  
everyone told me states were supposed to do with constraints.

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

Understood.  But, then I come across a case where a user class (the  
debugger console) really needs to know if there are constraints on an  
argument, so...

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

That is true now.  That is the way it has been for most of the history  
of LZX, there was a brief time where I broke that.

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

Yes, you are exactly right here.  So, there needs to be some other  
interface for removing a constraint on an attribute.

It sounds like __LZhasConstraint (or something like it) should be made  
public.  Perhaps it should return the constraint method name when an  
attribute is constrained, so you can use removeConstraintMethod to  
remove the constraint if you want to override it?