commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tobr...@transolutions.net (O'brien, Tim)
Subject RE: [EL] instanceof
Date Fri, 07 Feb 2003 21:27:26 GMT
> 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

--------
Tim O'Brien 


> -----Original Message-----
> From: Henri Yandell [mailto:bayard@generationjava.com] 
> 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:robertburrelldonkin@blueyonder.co.uk]
> > > 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: 
> commons-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: 
> > > > commons-dev-help@jakarta.apache.org
> > > >
> > >
> > >
> > > 
> --------------------------------------------------------------------
> > > -
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: 
> commons-dev-help@jakarta.apache.org
> > >
> > >
> >
> >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 



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


Mime
View raw message