I think the ability to construct Java objects in EL adds lots of
expressive power to the language, and will be useful to all EL users,
including CDI's. True, EL in bean-containers just want to deal with
bean properties mostly (and that's why method calls was not included in
EL 1.0), but I'm sure users using EL in stand alone environments would
want to do more. Since we already allow arbitrary method calls, it just
seem incomplete without constructor calls.
Ah, at least you don't object to it, so that's good! :-)
Kin-man
On 08/23/11 02:43, Pete Muir wrote:
> I don't think this feature is particularly useful for CDI users, and as Mark says it adds clutter to the spec, so I don't want to express support for it. However, as I don't have extensive experience of EL usage outside of bean-container environments such as CDI, I can't comment on applicability in those environments, so can't really say we shouldn't include it either. So I'm sitting on the fence ;-)
>
> For the proposal I think your syntax is fine.
>
> On 16 Aug 2011, at 18:12, Kin-man Chung wrote:
>
>
>> 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
>>>
>>>
>>
>