commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject Re: New Sandbox Component Proposal: Commons JSON
Date Thu, 30 Apr 2009 20:50:20 GMT



--- On Thu, 4/30/09, Christian Grobmeier <grobmeier@gmail.com> wrote:

> From: Christian Grobmeier <grobmeier@gmail.com>
> Subject: Re: New Sandbox Component Proposal: Commons JSON
> To: "Commons Developers List" <dev@commons.apache.org>
> Date: Thursday, April 30, 2009, 2:25 PM
> Matt,
> 
> > I don't know about folks you (or I) know face-to-face,
> but I know that several ASF committers and members have
> popped up around the ANTLR lists over the years, including,
> off the top of my head, myself, Torsten, O.Ziegermann, H.L.
> Ship, and probably others.  I personally am quite
> comfortable with ANTLR 2.x but need to really take the time
> to play with ANTLR 3.  The argument _for_ using parser
> generators is that those who use them feel the grammar is
> easier to digest (it's smaller) than the equivalent Java
> code.  It's something else again to debug ANTLR
> parsers/treeparsers, but it's far from impossible.  Once
> you get used to knowing what to look for it's actually
> fairly easy.  I don't say any of this to disparage Yonik's
> work on Noggit (I've not looked at it); I am just airing my
> understanding of the motivations for using grammars and
> parser generators as opposed to hand-writing parsers.
> 
> 
> what you (and Torsten, he PMed me) are saying will surely
> make digg me
> more into antlr. At the moment I always felt that such a
> simple format
> like json doesn't need  such a tool like antlr, but
> maybe I am wrong
> and should rethink. However, Yoniks parser is very fast -
> antlr
> parsers should have same performance and should be memory
> efficient
> too.
> This can be checked, of course, and I will do that (when
> having some
> spare time left :-)).
> 

Cool--note that ANTLR 3 is designed to be much faster than ANTLR 2 IIRC.

-Matt

> Thanks!
> 
> Christian
> 
> 
> >
> > -Matt
> >
> >> > I always scratch my head when I hear "there
> are
> >> dependencies!" when any application I create or
> use always
> >> has dependencies. I wonder how much redundancies
> and bug
> >> fixes would be removed if, for example, all Apache
> Java code
> >> (or even just the Commons code) went the other way
> and did
> >> depend on each other. You might argue we would end
> up in
> >> 'jar hell' but that might force us to better draw
> boundaries
> >> between components and fix bugs :)
> >>
> >>
> >> In maven age I don't feel bad with dependencies,
> but one
> >> json lib did
> >> depend on asm version 1 once, and hibernate
> upgraded to asm
> >> version 2,
> >> and that gave me nightmare. I ended up with
> opening my json
> >> package
> >> and copied all version 1 files into it with own
> package
> >> name. I
> >> recompiled, brought this to my repos and so on.
> This was
> >> hell (cause
> >> my customer didn't want to pay the time).
> >>
> >> For me json is so basic, that we can do everything
> without
> >> any
> >> dependencie. And a basic lib should not have any,
> I think.
> >>
> >> Thanks!
> >>
> >> Christian
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 
> 


      

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


Mime
View raw message