Skip Menu |

This queue is for tickets about the Business-CreditCard CPAN distribution.

Report information
The Basics
Id: 78803
Status: open
Priority: 0/
Queue: Business-CreditCard

People
Owner: Nobody in particular
Requestors: NEILB [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: 0.31
Fixed in: (no value)



Subject: Don't export functions by default
This is a suggestion: I think the module shouldn't export any functions by default, but should force users to explicitly important the functions they want to use. And while I'm here ... :-) The function name validate() is a bit generic, so runs the risk of clashing with a user function.
On Sun Aug 05 19:06:39 2012, NEILB wrote: Show quoted text
> This is a suggestion: I think the module shouldn't export any > functions by default, > but should force users to explicitly important the functions they want > to use. > > And while I'm here ... :-) > > The function name validate() is a bit generic, so runs the risk of > clashing with a user function.
Taking the very long view, I don't disagree with you, but in the medium-term, such an incompatible change would cause far more problems for existing users of the module. Perhaps 4.0 could start giving you a depreciation warning you if you don't import the functions you need explicitly (and change the name of "validate"?), and at least a few years later 5.0 could change over. In the short-term, you should be able to explicitly specify that you don't want things exported by default in the use statement: use Business::CreditCard (); This should probably be added to the documentation. Thanks.
Sounds good. You could add new function names, and then support the old names for backwards compatibility, phasing them out in the same schedule you outlined. Maybe you could support both styles of export as well? If you write: use Business::CreditCard; Then you'd get all functions, as now. But if you write: use Business::CreditCard qw(validate); Then you'd only get the function you asked for. Not sure if there's a standard way to do this though, and it might cause more confusion/harm than good :-)
On Fri Aug 10 09:56:01 2012, NEILB wrote: Show quoted text
> Sounds good. > > You could add new function names, and then support the old names for > backwards > compatibility, phasing them out in the same schedule you outlined.
In 0.36, I added validate_card() as the new name for validate(). Show quoted text
> Maybe you could support both styles of export as well? If you write: > > use Business::CreditCard; > > Then you'd get all functions, as now. But if you write: > > use Business::CreditCard qw(validate); > > Then you'd only get the function you asked for. > > Not sure if there's a standard way to do this though
Actually, that's exactly how Exporter works. Old interface, no incompatible changes (validate, cardtype and generate_last_digit are exported into your namespace): use Business::CreditCard; Declare you want nothing exported: use Business::CreditCard (); Declare you just want validate_card and cardtype: use Business::CreditCard qw( validate_card cardtype ); Declare you want the future default ( validate_card, cardtype and receipt_cardtype ); use Business::CreditCard qw( :NEW ); Long-term, I plan to eventually stop exporting validate() by default (and everything else?), but as this is a backwards-incompatible change, it will be a while. In the mean-time, you can explicitly ask for what you want (or don't) exported as above. Thanks!