spring-framework/org.springframework.expression
Andy Clement d69e9ef038 moved some TODOs out into here 2008-08-16 01:57:31 +00:00
..
.settings Modified public interface to expression parsing 2008-08-11 18:37:11 +00:00
src fixing TODOs 2008-08-16 01:57:13 +00:00
.classpath remove currently unnecessary dependencies 2008-08-12 22:05:06 +00:00
.project Changed project name from spring-binding to org.springframework.expression 2008-08-12 21:50:59 +00:00
build.xml Initial code checkin 2008-07-11 06:34:50 +00:00
ivy.xml Modified public interface to expression parsing 2008-08-11 18:37:11 +00:00
pom.xml Initial code checkin 2008-07-11 06:34:50 +00:00
readme.txt moved some TODOs out into here 2008-08-16 01:57:31 +00:00
template.mf Modified public interface to expression parsing 2008-08-11 18:37:11 +00:00

readme.txt

List of outstanding things to think about - turn into JIRAs once distilled to a core set of issues

High Importance

- In the resolver/executor model we cache executors.  They are currently recorded in the AST and so if the user chooses to evaluate an expression
in a different context then the stored executor may be incorrect.  It may harmless 'fail' which would cause us to retrieve a new one, but 
can it do anything malicious? In which case we either need to forget them when the context changes or store them elsewhere.  Should caching be
something that can be switched on/off by the context? (shouldCacheExecutors() on the interface?)

Low Importance

- For the ternary operator, should isWritable() return true/false depending on evaluating the condition and check isWritable() of whichever branch it
would have taken?  At the moment ternary expressions are just considered NOT writable.

Syntax

- are distanceto or soundslike any use?