On Fri, 7 Feb 2003, O'brien, Tim wrote:
> Date: Fri, 7 Feb 2003 15:27:26 -0600 > From: "O'brien, Tim" <[EMAIL PROTECTED]> > Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > To: 'Jakarta Commons Developers List' <[EMAIL PROTECTED]> > Subject: RE: [EL] instanceof > > > I meant to reply to this on Taglibs earlier. > > > > I imagine EL will not be able to implement it until it is in > > the JSP 2.0 specification as, as far as I know, commons-el is > > the EL component of the JSP 2.0 spec. > > > > But I could be utterly wrong :) > > I think you are right, I'm just curious. > > I understand that it is dependent on a JCP developed spec, was just > wondering if ASF could (or even wanted to) provide functionality outside of > the specification - EL is a part of the JSTL spec - JSR-052 and a port of > the JSR-152. > > Seems like the commons at ASF is full of packages that frequently extend the > functionality of the existing frameworks - beanutils and collections. I'm > just curious as to the direction of commons-el. If JSR-152 Section JSP.2.4 > tells developers not to use "instanceof", it seems like it would be harmless > to implement this as a BinaryOperator > The charter of the commons-el package was *specifically* to implement the spec requirements (so that we can use it in Tomcat and JSTL). That's a different kind of charter than some of the other packages. One thing you might investigate is seeing if "instanceof" support could get added into JEXL, which effectively has a charter to be a superset of the standard EL implementation. > -------- > Tim O'Brien Craig > > > > -----Original Message----- > > From: Henri Yandell [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, February 06, 2003 10:20 PM > > To: Jakarta Commons Developers List > > Subject: Re: [EL] instanceof > > > > > > I meant to reply to this on Taglibs earlier. > > > > I imagine EL will not be able to implement it until it is in > > the JSP 2.0 specification as, as far as I know, commons-el is > > the EL component of the JSP 2.0 spec. > > > > But I could be utterly wrong :) > > > > Hen > > > > On Thu, 6 Feb 2003, O'brien, Tim wrote: > > > > > In JSTL Spec 1.0, section A.4, the keyword "instanceof" seems to be > > > reserved for future use. Would the commons-el group consider > > > implementing instanceof as a BinaryOperator. I was fooling around > > > with my working copy, and it looks as if it is as easy as > > adding a new > > > error message, a new operator class and making a small > > modification to > > > ELParser.jj. > > > > > > Is this something [el] would be interested in pursuing. > > > > > > -------- > > > Tim O'Brien > > > > > > > > > > -----Original Message----- > > > > From: robert burrell donkin > > > > [mailto:[EMAIL PROTECTED]] > > > > Sent: Monday, February 03, 2003 11:39 AM > > > > To: Jakarta Commons Developers List > > > > Subject: Re: [EL] Promotion to jakarta-commons? > > > > > > > > > > > > hi Jan > > > > > > > > it's not the information - but the procedure that's > > concerning. i'm > > > > worried that later someone might say 'EL shouldn't be in > > the commons > > > > since there wasn't a proper VOTE with a proper procedure' - and > > > > they'd be right. > > > > things like this have a history of blowing up sooner or later. > > > > > > > > i don't think that there's any chance of EL being > > rejected but i'd > > > > really like to have a proper [VOTE] thread with a proper proposal > > > > for the archives. if i have to, i will propose this VOTE > > myself but > > > > it'd be better > > > > coming from yourself. > > > > > > > > - robert > > > > > > > > On Monday, February 3, 2003, at 05:16 PM, Jan Luehe wrote: > > > > > > > > > Hi Rod, > > > > > > > > > >> I'm +1 on moving [EL] to commons proper, but -1 on promoting > > > > >> components this casually. If this is meant to be a > > > > binding vote on > > > > >> promoting EL, it ought to be on a [VOTE] thread, and include a > > > > >> proposal that "identif[ies] the rationale for the package, > > > > its scope, > > > > >> its interaction with other packages and products, the Commons > > > > >> resources, if any, to be created, the initial source from > > > > which the > > > > >> package is to be created, the coding conventions used for > > > > the package > > > > >> (if different from the Sun coding conventions), and the > > > > initial set > > > > >> of committers." (#17 at > > > > >> http://jakarta.apache.org/commons/charter.html). > > > > > > > > > > actually, I think all the information you requested is already > > > > > provided in jakarta-commons-sandbox/el/PROPOSAL.html, which I > > > > > circulated to this list when originally proposing this project. > > > > > > > > > > Please let me know if you need any additional information. > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > Jan > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > - > > > > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > > > > For additional commands, e-mail: > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > - > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]