[Laszlo-dev] Constraint function generator

P T Withington ptw at openlaszlo.org
Wed Feb 20 10:07:21 PST 2008


You'll want to follow closely http://jira.openlaszlo.org/jira/browse/LPP-5452

However we go, there is a flag day to do this when the compiler and  
the LFC must be changed in sync.  IWBN to fix everything at once.

The pattern I have been using is `$lzc$` as a prefix and  
`_<qualifier>` as a suffix.  So, for instance, the setter method for  
`foo` is called `$lzc$foo_setter`, and I would make the dependencies  
method for `Fcn` be `$lzc$Fcn_depenencies`.

[It would be a groovy optimization to have the unparser compress all  
the $lzc$ names in production mode.]

On 2008-02-20, at 12:34 EST, Donald Anderson wrote:

> Did we come up with a decision for the new dependency function naming?
> Since there are recursive dependency computation, I'll need to know  
> how to call
> (and name) the new functions.  At the moment (using the old naming  
> style), the expression
>     a.b.c + this.something.Fcn(1)
>
> Returns this dependency array:
>    [a.b,  
> "c"].concat(this.something.Fcn.hasOwnProperty("dependencies") ?  
> this.something.Fcn.dependencies(this, this.something, 1) : [])
>
> If we use $lzsc$dep$Fcn for function Fcn, then this becomes:
>    [a.b, "c"].concat(this.something.hasOwnProperty("$lzsc$dep 
> $Fcn") ? this.something.$lzsc$dep$Fcn(this, this.something, 1) : [])
>
> I think we discussed this, not sure what was decided.
>
> - Don
>
> On Feb 20, 2008, at 5:05 AM, P T Withington wrote:
>
>> On 2008-02-19, at 19:00 EST, Donald Anderson wrote:
>>
>>> Henry,
>>>
>>> I have the constraint function generator mostly ready.
>>>
>>> First question - do we need an option to compute meta references?
>>> That's apparently a compile time option, but I don't see when it's  
>>> turned on.
>>
>> That was a failed experiment.  Correct, but determined to be too  
>> slow.  For now, we are just keeping the code as a reference  
>> implementation, turned off.  It is trying to solve the problem that  
>> if a constraint says `a.b.c`, we only listen for `c` changing in  
>> `a.b`; if `b` changes in `a`, we won't notice.
>>
>>> In my current version, I am accepting as arguments 1) the name of  
>>> the original function,
>>> and 2) the source for the function, for the moment I expect the  
>>> source
>>> to look just like what you are now generating.
>>>
>>> I am returning the source of a function with the name  
>>> XXX_dependencies.
>>
>> I agree with you and Henry that it will be more useful going  
>> forward if you accept an arbitrary expression (as a string) and  
>> return the expression that computes the dependencies for that (also  
>> as a string).  Thus, to retrofit your code to the current "pattern"  
>> you would analyze the expression that is the second argument to  
>> setAttribute in the current constraint functions.
>>
>> Are you doing this in RingDing?  I think that would be the best  
>> place, since then we can test against the known-working test cases.
>>
>>> For example, input source is this: (culled from where this string  
>>> is made in NodeModel.java):
>>>
>>> ===
>>> function $base$2Fbasefocusview$2Elzx_282_41_x_always () {
>>> #pragma 'constraintFunction'
>>>
>>> #pragma 'withThis'
>>> this.setAttribute("x",
>>> #beginAttribute
>>>
>>> #file base/basefocusview.lzx
>>> #line 282
>>>                                       -classroot.offset
>>> #endAttribute
>>> )}
>>> ===
>>>
>>> Output source is currently:
>>>
>>> ===
>>> /* -*- file: Compiler.substitute#-1.1 -*- */
>>> function $base$2Fbasefocusview$2Elzx_282_41_x_always_dependencies  
>>> () {
>>> #pragma "warnUndefinedReferences=false";
>>> with (this) {
>>> return [classroot, "offset"]
>>> }}
>>> ===
>>>
>>> I'm thinking instead I could accept simply '-classroot.offset'
>>> and return just the text of the statements:
>>> with (this) {
>>>  return [classroot, "offset"]
>>> }
>>
>> I would leave out the `with (this)` and have that be an implicit  
>> burden on the callee.  (Especially because that is implicit in JS2  
>> method bodies).
>>
>>> Then you could name the function whatever you want or
>>> use it as a function expression.  Or I could return just the
>>> array (as an expression) like '[classroot, "offset"]' .  It depends
>>> on how you plan to use it,  vs. how much of the details you need  
>>> to know.
>>>
>>> - Don
>>>
>>> --
>>>
>>> Don Anderson
>>> Java/C/C++, Berkeley DB, systems consultant
>>>
>>> voice: 617-547-7881
>>> email: dda at ddanderson.com
>>> www: http://www.ddanderson.com
>>>
>>>
>>>
>>>
>>
>
>
> --
>
> Don Anderson
> Java/C/C++, Berkeley DB, systems consultant
>
> voice: 617-547-7881
> email: dda at ddanderson.com
> www: http://www.ddanderson.com
>
>
>
>



More information about the Laszlo-dev mailing list