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.
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.)
Mark