On 08/16/11 00:34, Mark Thomas wrote:
> On 12/08/2011 22:43, Kin-man Chung wrote:
>
>> I'd like to consider adding constructors in EL. We now can call
>> arbitrary methods (including static methods) with arguments in EL
>> expressions; so it seems natural that we should add constructor calls,
>> as we have all the syntactic elements already.
>>
> Just because we can, doesn't mean we should. The more syntax we add, the
> more complicated EL gets for users yet EL is mean to make things simpler.
>
> If there isn't a clear use case for a new feature, I don't think we
> should add it. To quote from the proposal:
> "... it is not the intention of this specification to turn EL into a
> general language and the original goal to keep it simple and easy to use
> will be followed."
>
>
I am glad that you agree with the quoted goal. In fact, I worry that
I'll have convince you guys to turn down requests for adding new EL
features for this JSR.
That said, it also does not mean that we should not add anything new.
We need to consider each new feature on it's own merits, and be very
sure that it is simple and useful. In general we should err on being
conservative.
I think we should add constructors in EL for the following reasons.
1. For completeness. We've added general method calls, yet we cannot
call the most important methods in a class: the constructors.
2. The syntax is simple. It looks and acts like a method call. No
new syntax is introduced.
3. It is useful. Lots of time we need to get to an object instance
in EL expressions, often temporarily. Example: Date. Currently, we'll
have to instantiate it in Java codes, and register it as an user managed
bean, and then after being used in the expression, delete it from the
managed beans. This is tedious and unnecessary. To be able to
instantiate an Java object in EL expressions will fill a gap in the
basic functionality. This to me is an obvious omission when methods
call was introduced in EL 2.2.
>> If we are to follow the Java syntax, such as 'new
>> com.acme.Sale("Europe")', we'll need to add "new" as a reserved word.
>> I think in the EL context, "new" is unnecessary, and can be omitted
>> without real problem. So here's the proposal.
>>
>> Constructor Syntax:
>>
>> T(<className>)(args)
>>
>> such as #{T(com.acme.Sale)("Europe")}.
>>
>> WDYT?
>>
> If we go this route - and at the moment I don't think we should - there
> also needs to be a way of assigning an identifier to the new object so
> it can be referred to later. There isn't much point being able to create
> a new object if you can't do anything with it.
>
>
But we already have such functionality in EL, with the use of an EL
variable. For instance, we can write
elProcess.setVariable("curDate", "#{T(java.util.Date)()"); //
Assign to curDate
elProcess.getValue("#{curDate.year}"); // use curDate in another
expression
>> I am less sure about adding constructors for arrays, as it'd add more
>> reserved words (e.g. primitive types) and complexities to the syntax.
>> And I'm not convinced of its usefulness. So this is a still a maybe.
>> Possible syntax:
>>
>> int[]{1,2,3}
>> T(java.lang.Object)[]{"string", T(com.acme.Sale)("Europe")}
>>
> The more I look at this, the more I think "If the user wants to do that
> they should use Java rather than EL".
>
>
That why I was hesitant to added array constructors. It falls into the
"complexity out-weighs its usefulness" category. We should can this
for now.
>> Further down the priority list is adding functionalities for
>> constructing collection objects. We may come back to this later when we
>> deal with collections, if we ever get to that.
>>
> There are other features that have been requested that have not yet been
> addressed. Maybe we would be better spending time working on those?
>
>
Agreed. I'll next compile such a list, and we can then prioritize them.
Thanks.
Kin-man
> Mark
>