spring-framework/org.springframework.expression
Andy Clement 83432fc14d fixing TODOs
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@61 50f2f4bb-b051-0410-bef5-90022cba6387
2008-08-16 01:56:58 +00:00
..
.settings Modified public interface to expression parsing 2008-08-11 18:37:11 +00:00
src fixing TODOs 2008-08-16 01:56:58 +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 TODO moved out to readme.txt which contains latest interesting issues - they should become JIRAs when the dust has settled 2008-08-16 00:13:38 +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.