I was thinking that too. Seems like a good compromise between compatibility
and cleanup.
On 10/23/07, Jörg Schaible <[EMAIL PROTECTED]> wrote:
>
> [EMAIL PROTECTED] wrote on :
>
> > That's certainly the solution of least impact and works for me. Sucks
> > that we would have to keep a whole depende
[EMAIL PROTECTED] wrote on :
> That's certainly the solution of least impact and works for me. Sucks
> that we would have to keep a whole dependency for one deprecated
> method in one deprecated class, but life is hard sometimes.
We may set it to optional though and point it out inthe release not
That's certainly the solution of least impact and works for me. Sucks that
we would have to keep a whole dependency for one deprecated method in one
deprecated class, but life is hard sometimes.
On 10/22/07, Niall Pemberton <[EMAIL PROTECTED]> wrote:
>
> On 10/23/07, Ben Speakmon <[EMAIL PROTECTED
On 10/23/07, Ben Speakmon <[EMAIL PROTECTED]> wrote:
> After refactoring EmailValidator to use InetAddressValidator, I went to get
> rid of (or at least deprecate) isValidIpAddress. However, it takes a
> parameter of type Perl5Util from oro. Since it's a protected method, we
> can't eliminate it in
After refactoring EmailValidator to use InetAddressValidator, I went to get
rid of (or at least deprecate) isValidIpAddress. However, it takes a
parameter of type Perl5Util from oro. Since it's a protected method, we
can't eliminate it in a point release, but we also want to get rid of oro
for 1.4,
