[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