classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: java.net.URI implementation


From: Dalibor Topic
Subject: Re: java.net.URI implementation
Date: Mon, 10 Feb 2003 16:57:01 -0800 (PST)

hi Giannis,

--- Giannis Georgalis <address@hidden> wrote:
> Dalibor Topic <address@hidden> writes:
> 

> "reg_name"). However any URI that contains spaces
> where it shouldn't
> is considered valid for this regex. To be honest, I

You're right. That is supposed to be caught in the
post-processing of matched tokens which I have not
written ;)
 
> > That's nice. But it's overkill. 
> > 
> > You can achieve the same effect by using the
> regexp to
> > separate URI components and doing some
> post-processing
> > (preferably using simple regexps) on the generated
> > Strings to ensure they contain only allowed
> > characters, to get the port number of hierarchical
> > URIs etc.
> 
> This regexp only breaks down the problem in smaller
> parts. And the
> post-processing you are talking about, is parsing
> that small parts to
> ensure that the uri is valid (and to fill the host,
> userinfo,
> etc. Strings).

Exactly. A straightforward, 'by-the-rfc' approach, I'd
assume. I didn't have a need to write a full parser,
so I didn't, as I only needed to have basic URI
parsing for Saxon.

> > I could have implemented URI parsing using a
> parser
> > generator, but it seemed to me like the wrong
> solution
> > to the problem: instead of simple regexp and 20
> lines,
> > you get a compile time dependency on a parser
> > generator, x lines for the grammar + y lines for
> the
> > generated code. I think your grammar alone is
> bigger
> > than my parsing code.
> 
> Yes I decided to make the parser hand-written. I
> agree that my
> initial thought was not wise. But as you state, your
> implementation
> was not full, so do not compare it with a proper
> parser because it is
> not.

I'm sorry for using a straw man argument here. I
didn't really notice it.
 
> Provided that classpath's java.util.regex.Matcher,
> java.util.regex.Pattern classes are not implemented,
> I wouldn't want
> to use regexps. Though I can follow the same
> philosophy and break the
> initial problem in the smaller parts you are
> suggesting and then go
> on from there, so it would be easy, when the regex
> classes are
> implemented and proved more efficient, to switch.
> No hard feelings ;-)

I'm using the gnu.regex package in Kaffe with their
java.util.regex wrapper which is supposed to be merged
into GNU Classpath, as far as I know. The discussion
seems to flare up every few months, but nothing has
came out of it so far, I think, except that everybody
agrees it would be a good thing. ;)

best of luck with the code, I'll be happy to merge it
into kaffe when it arrives into Classpath.

cheers,
dalibor topic

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com




reply via email to

[Prev in Thread] Current Thread [Next in Thread]