Re: [Smartfrog.org-JIRA] Created: (SFOS-23) LAZY vector evaluation is broken

(Non-primitive) Lists always get turned into a function whether or not
they are lazy - it is just that you only see this if you have it lazy as
otherwise the function is evaluated to create a Java Vector. Actually a
more accurate definition is that a list IS a function.

In the case of function parameters (the atributes) these are resolved if
they are not lazy, and not resolved if they are. Seems reasonable, but
if the function is evaluated at run-time, only changes to the lazy
attributes are then detected and used in the function evaluation. This
again seems OK since otherwise one would have put LAZY in front of the
reference. Hence I originally made functions, when LAZY, that way. (It
broke when I changed the way LAZY propagation happens, using exceptions
rather than a specific return value, but that's a detail now fixed).

Now with assertions that need to be checked at run-time - I felt that
all parameters to the assertion need to be considered LAZY (even if not
so specified) otherwise run-time changes to the attribute values would
not result in a predicate failure when checked at run-time as they are
pre-bound to the static value. But this means that assertions (which are
just special kinds of functions) have a different semantics to functions
on deciding what to do with reference parameters that need evaluation at
runtime.

I am still thinking...

As for your example, this only breaks if the other attributes that you
would resolve at compile time are no longer there when you resolve at
runtime. This typically happens when you have a reference to an
attribute that is outside of sfConfig as this suffers from the "changing
root" syndrome. BTW note that I am not suggesting I change the way
functions work - it is more a case that I want to reconsider the new
concept of lazy assertion - so your example is safe (for now...)

Patrick


-----Original Message-----
From: smartfrog-developer-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
[mailto:smartfrog-developer-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of
Steve Loughran
Sent: 19 October 2006 14:06
To: smartfrog-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Smartfrog-developer] [Smartfrog.org-JIRA] Created:
(SFOS-23) LAZY vector evaluation is broken

Goldsack, Patrick wrote:
> Interesting issue. There are two possible interpretations of what the 
> correct behaviour is here, both of which have the current result as a 
> bug but with different results after the fix...
> 
> (1) all non-lazy attributes are resolved.
> (2) no attribute is resolved if one is LAZY. 
> 
> Functions used to do (1) and I have fixed it to do it this way again 
> (and will check into subversion as soon as it lets me).
> Assertions do (2) as I had already handled the issue in this case and 
> chose this option for good reasons.
> 
> Now I don't really like functions and assertions doing different 
> things, but which is correct? There are advantages both ways. I 
> presume that your example will break if I do (2) for functions as you 
> seem not to have the static link references resolvable dynamically, so

> I will probably do (1) in both cases.
> 
> The compromise might be to add an additional possible sfAssertionPhase

> attribute value - dynamicUnresolved - that will cause none of the 
> attributes to be resolved in the dynamic version of the assertion. I 
> have been thinking of adding the same notion of phase in a function - 
> sfFunctionPhase - that has the same basic semantics as the 
> sfAssertionPhase.
> 
> I won't set this bug to resolved until I have decided and fixed how to

> handle the assertion case.

I've marked it as closed as the behavior that otherwise broke appears
fixed. I've added a test base, but am not sure that it demonstrated the
problem reliably.

The issue about functions vs. assertions is irrelevant to me as I am not
explicitly doing a function, I'm doing a list

List  ["a", b:c:d,LAZY f:g,e];

the fact that it gets turned into a function if there is a lazy
reference is an implementation detail.

Now imagine I have a list

  ["a", b:c:d, f:g,e]

and

f extends Compound {
  g LAZY h;
}

My list "List" shouldnt have to break just because one reference further
down the chain is lazy, which is exactly what will happen if you switch
to (2).

-steve



Seems me that non-LAZY references should be resoved early, LAZY ones
late.

------------------------------------------------------------------------
-
Using Tomcat but need to do more? Need to support web services,
security?
Get stuff done quickly with pre-integrated technology to make your job
easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Smartfrog-developer mailing list
Smartfrog-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/smartfrog-developer

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642