Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Message-ID: <51E3B455.4070905@apache.org>
Date: Mon, 15 Jul 2013 09:35:33 +0100
From: Mark Thomas <markt@apache.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: svn commit: r1503006 -
 /tomcat/trunk/java/org/apache/el/lang/ELSupport.java
References: <20130714175707.5FC0923888E2@eris.apache.org>
 <CABzHfV=yHThVfLg-SBsPqdGP8cdcyPrHYB+TTNvcXUs+AeF8QA@mail.gmail.com>
In-Reply-To: 
 <CABzHfV=yHThVfLg-SBsPqdGP8cdcyPrHYB+TTNvcXUs+AeF8QA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 15/07/2013 00:16, Konstantin Kolinko wrote:
> 2013/7/14  <markt@apache.org>:
>> Author: markt
>> Date: Sun Jul 14 17:57:06 2013
>> New Revision: 1503006
>>
>> URL: http://svn.apache.org/r1503006
>> Log:
>> Special handling to handle the ambiguity of {} which could be an empty Set or an empty Map

> 1. It is odd that I see no clarification in the spec regarding this
> ambiguity. It the value is exposed as an Object, the difference might
> be seen.

There is a clue but I didn't understand what it meant until after I knew
about the problem and went looking more carefully at the spec.

The JavaCC grammar in the spec only mentions Maps, not Sets, but if you
look at the grammar for a Map entry then the value component is
optional. So the spec is using a Map to back both Sets and Maps.

Personally, I think that creates more scope for confusion since it means
rather than handling the empty set as a special case, every Set is a
special case and there would have to be some general "coerceMapToSet"
code that create all sorts nasty edge cases.

> 2.  I am a bit puzzled why there is exact equality test in "type ==
> Map.class" (whether type can be a subclass of Map).

Two reasons.
1. The test is expecting Map so this means the test will pass.
2. I'm not sure it would ever make sense to try and coerce a result to
anything other than Map as the specification makes no promises as to
which Map implementation it might use.

> Well, EL does not promise to provide any specific Map implementation,
> so it is unlikely that anyone notices a difference.

I think this is my point 2 above.

> 3. It would be safer if instead of a generic "is set empty" check we
> could check that this set was indeed created by our EL.  E.g. use some
> sentinel object.

Yes. I think that is possible. I'll take a look.

> 4. Are sets and maps created by EL supposed to be immutable (e.g.
> wrapped by Collections,unmodifiableSet())?

I don't see anything in the specification that requires that.

]> I just hope that such sequence of assignments is invalid:
> 
> <c:set var="foo" value="${{}}"/>
> <c:set target="${foo}" property="key" value="value" />
> <c:out value="${foo['key']}" />

That looks to be valid to me.

> Also, if I understand correctly, the same could be done using a semicolon:
> 
> ${  foo={}; foo['key']='value'; fn:escapeXml(foo['key'])}

Yes.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org