On 21 Feb 2010, at 08:50, Christoph Beck wrote:
> On 19.02.2010 20:25, Kin-man Chung wrote:
>> First, let me introduce Christoph Beck. Christoph is the creator of
>> JUEL (http://juel.sourceforge.net), a quality implementation of the
>> EL 2.1, and more.
>>
> Thanks (for the quality word)... Before discussing usage enhancements and new features, I would like to make a proposal to clarify and improve the current API. From my experience with JUEL and various user discussions, some of the major sources of trouble are:
> - ELContext mixes parse time and evaluation time concerns. Users don't understand that variables and functions are only used at parse time while resolvers are only used at evaluation time. The EL should emphasize this important concept by splitting the ELContext into ELParseContext and ELEvaluationContext.
> - The EL currently does not provide a generalized concept for type conversions. Many users would like to introduce their own conversion rules. It's pretty easy to support this by introducing an ELTypeConverter interface and exposing it in ELEvaluationContext. The type converter would be used by the AST nodes for operand conversions but also by ELResolver#invoke(...) to convert method parameters.
>
> I'm not sure in what way we have to deal with backward compatibility. Do we need binary compatibility (i.e legacy code runs without recompilation)?
> Anyway, to summarize, here's some rough code describing the proposed API changes:
>
> public interface ELParseContext {
> public FunctionMapper getFunctionMapper();
> public VariableMapper getVariableMapper();
> }
>
> public interface ELTypeConverter {
> public <T> T coerceToType(Object value, Class<T> type) throws ELException;
> }
>
> public abstract class ELEvaluationContext {
> // ... everything from ELContext except the two methods that went into ELParseContext plus...
> public ELTypeConverter getTypeConverter();
Allowing type conversion to be pluggable (allowing the current type coercion to be modified/replaced) sounds like a very useful feature!
I also like you ideas on how to split these interfaces.
> }
>
> The methods in ExpressionFactory to create value/method expressions would now take an ELParseContext parameter. Furthermore, an ExpressionFactory implements the ELTypeConverter interface:
>
> public abstract class ExpressionFactory implements ELTypeConverter {
> // ...
> public abstract ValueExpression createValueExpression(ELParseContext context, ...);
> public abstract MethodExpression createMethodExpression(ELParseContext context, ...);
> }
It seems odd having ExpressionFactory implement ELTypeConverter. I think we would be much better off making this have it's own stage in the EL evaluation pipeline...