Are there any other opinions on this? If not, I'll propose the following:
The symbols for string concatenation operator are:
1. "cat", and
2. "+"
For 1. the operands are coerced to String and then the results
concatenated. For 2, concatenation happens if one of the operands is a
String, and then the other operand is coerced to String and then the
results concatenated. The incompatibility with EL 2.2 is noted.
As a head's up, I'll ready a draft for EDR (early draft review) next
week for the experts to review, before it is published.
Kin-man
On 02/16/12 11:34, Kin-man Chung wrote:
> On 02/16/12 03:09, Mark Thomas wrote:
>> On 15/02/2012 22:50, Kin-man Chung wrote:
>>> Thanks for the feed back on EL 3.0.
>>>
>>> EL has currently another xml special character, namely,<. How is this
>>> handled in facelets?
>>>
>>> Regardless, it seems prudent to pick another symbol for concatenation.
>>> Consider the expression
>>>
>>> foo&
>>>
>>> which in EL means foo concatenate amp. Already I can see there may be
>>> confusions. :-)
>>>
>>> What does other EGs think about this?
>> There is a lack of hard data in the original report. Before we consider
>> changing this I'd like to see some harder evidence than "I imagine".
> It is hard to get hard evidence when EL 3.0 is not released. To
> foresee problems ahead of time is part of the design. I certainly do
> not want to cause problems for facelet and xml users since they would
> be our important users.
>
>>> I recall the other symbols we considered:
>>>
>>> 1. ++
>>> 2. #
>>> 3. +=
>>> 4. !
>> Of those, "+=" would be my preference. I'd also like to throw "+" into
>> the ring.
>>
> I'm OK with +=, if only because it is least likely to be used elsewhere.
>
> I'm also OK with '+', although that'd break backward compatibility. If
> we use it, it should work like that in JDK, i.e. it is a concatenation
> if and only if one of the operands is a String. This is probably the
> most "natural" for users and is worth the small incompatibility price.
>
>>> In any case, we should also allow the string "concat" as an operator,
>>> like "eq" or "lt" etc.
>> I agree a string form should also be supported. I'd suggest something
>> shorter as all the other string forms are two or three characters.
>> Possibilities:
>> cc
> This is a JSF reserved EL variable.
>> cat
> I vote for "cat".
>> ct
>> sc
>>
>> Mark
>>
> Kin-man
>>> Kin-man
>>>
>>> On 02/15/12 08:31, Bauke Scholtz wrote:
>>>> Hi,
>>>>
>>>> I saw the proposal for the new EL 3.0 string concatenation operator&.
>>>>
>>>> The idea is at its own great. However, since a XML special character
>>>> is been used, I wonder how it should be used in Facelets since that's
>>>> a XML based view technology which needs to go through a XML parser
>>>> first. I imagine that we'd need to escape the& as& everywhere.
>>>> This isn't very developer friendly. I'd suggest a different operator
>>>> symbol.
>>>>
>>>> Cheers, Bauke
>>>>
>