Re: [Smartfrog.org-JIRA] Created: (SFOS-23) LAZY vector evaluation is broken
Steve Loughran <[email protected]> Thu, 19 Oct 2006 14:05:40 +0100
| Newsgroups | gmane.comp.java.smartfrog.devel |
|---|---|
| Message-ID | <[email protected]> |
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