|
|
|
|
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.
|
|
|
|
|
- Enhance type locator interface with direct support for register/unregister imports and ability to set class loader?
|
|
|
|
|
- Should some of the common errors (like SpelMessages.TYPE_NOT_FOUND) be promoted to top level exceptions?
|
|
|
|
|
|
|
|
|
|
Syntax
|
|
|
|
|
|
|
|
|
|
- are distanceto or soundslike any use?
|
|
|
|
|
- should the 'is' operator change to 'instanceof' ?
|
|
|
|
|
- in this expression we hit the problem of not being able to write chars, since '' always means string:
|
|
|
|
|
evaluate("new java.lang.String('hello').charAt(2).equals('l'.charAt(0))", true, Boolean.class);
|
|
|
|
|
So 'l'.charAt(0) was required - wonder if we can build in a converter for a single length string to char?
|
|
|
|
|
Can't do that as equals take Object and so we don't know to do a cast in order to pass a char into equals
|
|
|
|
|
We certainly cannot do a cast (unless casts are added to the syntax). See MethodInvocationTest.testStringClass()
|
|
|
|
|
|
