On 08/14/12 14:15, Mark Thomas wrote:
> On 13/08/2012 19:22, Kin-man Chung wrote:
>
>> Another feedback for the public review raised the issue of how EL 3.0
>> will work with Java SE 8.
>>
>> SE 8 is not out yet, but will be next year. It also contains Lambda and
>> some collection operators, so it become important that EL 3.0 and SE 8
>> works together well. The syntax for Lambda is the same in EL and SE8,
>> so we are OK there. The area of collection operation support is more
>> problematic, because there is only a smaller set of operations in SE8
>> and their names and behaviors are not the same as those in EL.
>>
>> What is important is the new methods added in SE 8 will be invoked
>> through reflections in EL (we'll need to get this to work in
>> BeanELResolver). To avoid invoking the unintended methods in EL, we'll
>> need a way to name our methods differently from Java names. Suggestions
>> so far:
>>
>> 1. Begins with a capitol, e.g.
>> products.Where(p->price> 10).Select(p->p.name)
>> 2. Prepend with an el$, e.g.
>> products.el$where(p->price> 10).el$select(p->p.name)
>> 3. Prepend with a $, e.g.
>> products.$where(p->price> 10).$select(p->p.name)
>>
>> Personally, I think 1. is too easily confused with ones in lower case,
>> and 2. is too ugly, 3. is a good compromise.
>>
>> Comments?
>>
> I'm not familiar with Java 8 so apologies if this doesn't make any sense.
>
> If EL 3.0 is a superset of Java 8, why doesn't EL 3.0 uses the
> names/behaviours as defined in Java 8 and add the extra EL 3.0 ones on
> top of that? Granted, we'll still have the same issue if Java SE adds
> extra methods so maybe we should have a separate naming convention but
> it still seems to be that alignment with Java 8 would be a good place to
> start.
>
>
The problem is this part of Java 8 is still under discussion, and
changing. The lambda spec lead sent me some sources, but with the
warning that "they are guarantied to look different a month later". :-)
We can change our names to match theirs, but what if the behavior are
not exactly the same? we cannot even change ours to match theirs now
when the target is moving. Also, if we take some names from Java 8, and
some form Linq, wouldn't it be more confusing?
The other difficulty is Java 8 is introducing a new interface
java.util.Stream to encapsulate the idea of lazy evaluation in the
collection operations, but EL operators work with java.util.Iterables.
Since Stream does not exist in Java 7, we cannot really use it in our
implementation.
Using a different naming convention will make it clear that ours are
different from theirs.
> I agree 1 is too easy to get wrong.
>
> I actually prefer 2 over 3 since it is more explicit about what is going
> on. It also allows other xxx$ prefixes - such as container specific
> extensions - if required. (Not that I am planning any right now.)
>
>
I'm OK with 2 also.
Kin-man
> Mark
>
>