[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 23:28:00 +0100
- List-id: <jsr341-experts.el-spec.java.net>
On 14/08/2012 23:18, Kin-man Chung wrote:
> 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.
>> 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
> 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
> Using a different naming convention will make it clear that ours are
> different from theirs.
Fair enough. We can't be consistent with a moving target.
>> 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.