I've updated
http://java.net/projects/el-spec/pages/CollectionConstruction
reflect such change.
I've continued the implementation and the writeup on the query
operators. Although there are a lot of operators, the implementation
classes are all relatively small. After talking with other people in
the Javaee team, I think we should provide full support for LINQ. That
means that it is not optional, and includes all operators (where makes
sense).
I'll update (over time) the wiki on LINQ to clarify what'll be in EL 3.0.
Kin-man
On 12/02/11 12:59, Kin-man Chung wrote:
> As I mentioned before, it has been suggested that EL use the syntax
> that is being proposed for JDK 8 for collection literals.
>
> The current syntax for JDK 8 is as the following:
>
> 1. Set: {1, 2, 3}
> 2. List: ["one", "two", "three"]
> 3. Map: {"one": 1, "two": 2, "three": 3 }
>
> There is no literals for arrays. Presumably it can be accomplished
> with, for instance, new int[] {1,23} that is already in Java.
>
> Therefore I think we should also omit array literals, not only because
> JDK 8 does not have it, but also because a Java array does not
> implement a java.lang.Collection or java.lang.Iterable, so it cannot
> partake the query operators. This is not a big lost, because one can
> always construct an array from a List easily:
>
> ["one", "two", "three"].toArray()
>
> Other scripting languages, such as javascript or PHP, also do not have
> arrays, and use a list in place of an array whenever an array is needed.
>
> I am not sure if a Set literal is useful in EL, but am inclined to
> keep it for completeness.
>
> I also realize that a Map is not a collection, so in the query
> operations, we'll need to iterate over its Collection view, i.e.
> Map.entrySet. For instance, if salary is a map of name to annual
> amount, the following is a collection of names whose salary is greater
> then 10000.
>
> salary.where(#{p -> p.value > 10000}).select(#{p -> p.key})
>
> If there is no other opinions, I'll update the wiki page to reflect
> such changes.
>
> Thanks.
>
> Kin-man