|
|
|
List of outstanding things to think about - turn into tickets 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?)
|
|
|
|
- Expression serialization needs supporting
|
|
|
|
- expression basic interface and common package. Should LiteralExpression be settable? should getExpressionString return quoted value?
|
|
|
|
|
|
|
|
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?
|
|
|
|
- Expression comparison - is it necessary?
|
|
|
|
|
|
|
|
Syntax
|
|
|
|
|
|
|
|
- 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()
|
|
|
|
- MATCHES is now the thing that takes a java regex. What does 'like' do? right now it is the SQL LIKE that supports
|
|
|
|
wildcards % and _. It has a poor implementation but I need to know whether to keep it in the language before
|
|
|
|
fixing that.
|
|
|
|
- Need to agree on a standard date format for 'default' processing of dates. Currently it is:
|
|
|
|
formatter = new SimpleDateFormat("EEE, d MMM yyyy HH:mm:ss z", Locale.UK);
|
|
|
|
// this is something of this format: "Wed, 4 Jul 2001 12:08:56 GMT"
|
|
|
|
// https://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html
|
|
|
|
- See LiteralTests for Date (4,5,6) - should date take an expression rather than be hardcoded in the grammar
|
|
|
|
to take 2 strings only?
|
|
|
|
- when doing arithmetic, eg. 8.4 / 4 and the user asks for an Integer return type - do we silently coerce or
|
|
|
|
say we cannot as it won't fit into an int? (see OperatorTests.testMathOperatorDivide04)
|
|
|
|
- Is $index within projection/selection useful or just cute?
|
|
|
|
- All reals are represented as Doubles (so 1.25f is held internally as a double, can be converted to float when required though) - is that ok?
|