Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates
 209.85.212.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1360587911.1752.10.camel@ubuntu>
References: 
 <CAOGo0Va+OjUEee4R9r4AH+e7ThQ6CsUb+rBSnHvdwED75x=ggQ@mail.gmail.com>
	<1360587911.1752.10.camel@ubuntu>
Date: Mon, 11 Feb 2013 18:14:33 +0000
Message-ID: 
 <CAOGo0VbBvWGLy6EcUt85GHtGZAuxN9HoToGk0A_kVGwEWP6nFg@mail.gmail.com>
Subject: Re: InetAddressUtils - use of non-capturing groups
From: sebb <sebbaz@gmail.com>
To: HttpComponents Project <dev@hc.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

On 11 February 2013 13:05, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Mon, 2013-02-11 at 12:24 +0000, sebb wrote:
>> The IPv6 regexes use non-capturing groups - i.e. (?:pattern) - whereas
>> the IPV4 pattern uses capturing groups - i.e. (pattern).
>>
>> Just wondering why they don't all use non-capturing groups, given that
>> the patterns are only used in boolean matches() methods?
>>
>
> No reason. Just me being sloppy.
>
>> If it more efficient to use non-capturing groups, perhaps they should
>> be use throughout?
>>
>> If efficiency is not a concern, then the IPv6 patterns would be easier
>> to read if they used non-capturing groups, as that would mean the
>> colon would only appear as itself rather than sometimes as itself and
>> sometimes as part of (?:pattern). In some cases the pattern begins
>> with : which looks odd.
>>
>
> I think we should strive for simplicity over efficiency here. These
> regular expressions are already too complex for mere mortals. Anything
> that would make them more readable would be a good thing.

In which case, would you be OK if I extracted the common sections out?

For example, [0-9A-Fa-f]{1,4} appears several times; it could be
defined as IPV6_HEX_FIELD and then used to build up the other strings.

AFAIK, javac concatenates strings at compile time if they are
constants, so it would be no less efficient.

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

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