in reply to New Module Consideration?

With the caveat that I've never used either of the modules you're thinking about reinventing, I do have some thoughts.

Since you're basically adding new functionality, this is a case where you want to think about subclassing existing modules. Both of the two you mention are object-oriented, and so it seems you ought to be able to do this without much trouble (although Data::Validator::Item may pose slightly more of a challenge as it's designed as a factory class). Subclassing will have two major advantages: You'll inherit behavior that you don't want to replicate needlessly, and you won't further pollute the CPAN namespace. Compare Data::Validate::OO to, say, Data::FormValidator::Extensible.

Replies are listed 'Best First'.
Re^2: New Module Consideration?
by Aristotle (Chancellor) on Jan 01, 2003 at 02:38 UTC
    I think people should think about aggregation far more often than about inheritance. A has-a relationship is very likely to be more appropriate than an is-a one when the desired interface differs significantly from what the existing class already offers.

    Makeshifts last the longest.

[reply]

      I agree, if the interface is going to be drastically different then you should not try to subclass. To do so would probably involve overriding the parent's methods with dummy placeholders to prevent the user from accessing inherited but unwanted behavior. In this case though, I'd be surprised if it were not possible to expand the interface to allow extensible argument checking via this newrule method he's proposing, without breaking compatibility with the parent module. But if I'm wrong I fall back on my original caveat :^p

[reply]
[d/l]

In Section Meditations