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]> 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 a point release, but we also want to get rid of > oro > > for 1.4, but we can't without removing this protected method... bugger. > > > > For 1.4, obviously the entire class in o.a.c.validator is going to be > > deprecated and replaced with a soon-to-exist > > o.a.c.validator.routinesversion, but what should we do about this > > annoying problem? My gut says the > > evil of breaking compatibility at this one point is outweighed by the > good > > of getting rid of oro entirely, so I'd prefer to remove it and mark it > as an > > upgrade/release issue. > > IMO better to just copy the email/url validators over to the routines > package and work on them there - removing the ORO dependency - and > deprecate the old validators. Lets not break compatibility for the 1.4 > release. IMO having the full set of validators with no ORO dependency > is the main goal - if there are some old, deprecated versions around > that still depend on it - then in my mind the "oro not required" aim > has still been met. > > Niall > > > Thoughts? > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
