Return-Path: 
 <taglibs-user-return-5573-qmlist-jakarta-archive-taglibs-user=nagoya.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-taglibs-user-archive@apache.org
Received: (qmail 46821 invoked from network); 8 May 2003 20:59:56 -0000
Received: from exchange.sun.com (192.18.33.10)
  by daedalus.apache.org with SMTP; 8 May 2003 20:59:56 -0000
Received: (qmail 3741 invoked by uid 97); 8 May 2003 21:02:03 -0000
Delivered-To: qmlist-jakarta-archive-taglibs-user@nagoya.betaversion.org
Received: (qmail 3734 invoked from network); 8 May 2003 21:02:03 -0000
Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12)
  by nagoya.betaversion.org with SMTP; 8 May 2003 21:02:03 -0000
Received: (qmail 46215 invoked by uid 500); 8 May 2003 20:59:50 -0000
Mailing-List: contact taglibs-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:taglibs-user-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:taglibs-user-subscribe@jakarta.apache.org>
List-Help: <mailto:taglibs-user-help@jakarta.apache.org>
List-Post: <mailto:taglibs-user@jakarta.apache.org>
List-Id: "Tag Libraries Users List" <taglibs-user.jakarta.apache.org>
Reply-To: "Tag Libraries Users List" <taglibs-user@jakarta.apache.org>
Delivered-To: mailing list taglibs-user@jakarta.apache.org
Received: (qmail 46167 invoked from network); 8 May 2003 20:59:49 -0000
Received: from mail.ureach.com (HELO ureach.com) (63.150.151.36)
  by daedalus.apache.org with SMTP; 8 May 2003 20:59:49 -0000
Received: from www22.ureach.com (www22.ureach.com [172.16.2.50])
	by ureach.com (8.9.1/8.8.5) with ESMTP id QAA20772
	for <taglibs-user@jakarta.apache.org>; Thu, 8 May 2003 16:59:55 -0400
Received: (from nobody@localhost)
	by www22.ureach.com (8.9.3/8.9.1) id QAA24603;
	Thu, 8 May 2003 16:59:55 -0400
Date: Thu, 8 May 2003 16:59:55 -0400
Message-Id: <200305082059.QAA24603@www22.ureach.com>
Received: from [216.194.17.194] by www22.ureach.com via HTTP;
 Thu, 08 May 2003 20:59:55 GMT
To: "Shawn Bayern" <taglibs-user@jakarta.apache.org>
From: otisg  <otisg@ureach.com>
Reply-to: <otisg@ureach.com>
Subject: Re: RE: missing if/else syntax
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
X-vsuite-type: e
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Shawn, you are saying 'we', so it looks you participated in
decision making, or were at least close to it.
I'm just curious, why was c:choose chosen, insteaf of (a more
'natural') c:switch?

Lot's of programming languages use the switch keyword.  I don't
use any PL that uses choose keyword.  Does XSLT use choose?  If
so, why did they decide on choose, any idea?

Thanks,
Otis



________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag


---- On Thu, 8 May 2003, Shawn Bayern (bayern@essentially.net)
wrote:

> On Thu, 8 May 2003, Henri Yandell wrote:
> 
> > Nope:
> > 
> >  <c:either test="${ifTag.Existed}">
> >    <c:do>
> >      <c:either test="${another.Test}">
> >        <c:do>..</c:do>
> >        <c:or>..</c:or>
> >      </c:either>
> >    </c:do>
> >    <c:or>...</c:or>
> >  </c:either>
> > 
> > Which is just a <c:choose> switch statement anyway.
> 
> Heh.  This discussion is rapidly coming to resemble the expert
group's
> deliberations.  We considered many different variants -- those
listed here
> and even other, stranger beasts(*) -- and decided on
choose/when/otherwise
> for a few reasons, some of which have already been pointed
out:
> 
>  1. A parent <choose> tag plays by XML's rules, is
straightforward to
>     implement, and is in fact what XSLT (facing the same
problem) chose.
> 
>  2. It supports multiple branches more cleanly than if/else
>     constructs do when represented as XML tags.
> 
>  3. It drew a clean line between complex (multi-way)
conditions and simple
>     conditions (<c:if>) and allows them to be mixed
orthogonally and with
>     little confusion.  Simple conditionals with <c:if> NEVER
have an
>     effect on anything outside their immediate tag, whereas
<c:when>
>     and <c:otherwise> alter the flow within their parent tag.
> 
> Having said all this, decisions like this are necessarily made
with large
> doses of subjective intuition and judgment; it's possible and
even likely
> that different constructs will appeal for legitimate reasons
to different
> designers.  The EG picked the tags that generated the most
consensus and
> provided for the most function with the fewest primitives.
> 
> -- 
> Shawn Bayern
> "JSTL in Action"   http://www.manning.com/bayern
> 
> 
> (*) I believe I once floated the idea for a single tag called
<c:cond>
> that adapted to its environment depending on neighboring
<c:cond> tags to
> become a 2-way or multi-way condition as necessary.  Another
crazy idea
> involved open-ended mutual exclusivity achieved at runtime
with a tag
> called something like <c:exclusive label="...">; this tags
would prevent
> other <c:exclusive> tags with the same label -- and their
bodies -- from
> executing
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
taglibs-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
taglibs-user-help@jakarta.apache.org
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-user-help@jakarta.apache.org