[el-spec users] [jsr341-experts] Re: Changing the collection method names
- From: Mark Thomas <markt@...>
- To: jsr341-experts@...
- Subject: [el-spec users] [jsr341-experts] Re: Changing the collection method names
- Date: Tue, 14 Aug 2012 22:15:49 +0100
- List-id: <jsr341-experts.el-spec.java.net>
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.
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
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.)