Skip Menu |

This queue is for tickets about the Config-Std CPAN distribution.

Report information
The Basics
Id: 16804
Status: resolved
Priority: 0/
Queue: Config-Std

People
Owner: Nobody in particular
Requestors: david [...] kineticode.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.0.2
Fixed in: v0.0.3



To: bug-config-std [...] rt.cpan.org
From: David Wheeler <david [...] kineticode.com>
Subject: No Import Conflict Handling
Date: Thu, 29 Dec 2005 20:32:37 -0800
I ran into an issue when using Config::Std in a subclass of Module::Build. Module::Build defines a write_config() method, so when I used Config::Std, the write_config() method that it imported overrode the base class implementation. Needless to say, these are not the same kinds of functions at all. To get around this, for now, I'm calling the Config::Std functions directly: use Config::Std (); ... Config::Std::Hash::read_config($conf_file => my %conf); ... Config::Std::Hash::write_config(%conf); I'm uncomfortable with this approach because these functions are not documented. I have two proposed solutions for this issue: 1. Add Config::Std::read_config() and Config::Std::write_config(), document them, and allow them to be called directly with their fully- qualified names. 2. Allow the names of the functions to be imported to be modified, something like this: sub import { my %export = @_ || ( read_config => 'read_config', write_config => 'write_config', ); *{caller()."::$export{read_config}"} = \&Config::Std::Hash::read_config; *{caller()."::$export{write_config}"} = \&Config::Std::Hash::write_config; } Thanks! David
Subject: Re: [cpan #16804] No Import Conflict Handling
Date: Fri, 10 Feb 2006 10:18:52 +1100
To: bug-Config-Std [...] rt.cpan.org
From: Damian Conway <damian [...] conway.org>
David Wheeler via RT wrote: Show quoted text
> I ran into an issue when using Config::Std in a subclass of > Module::Build. Module::Build defines a write_config() method, so when > I used Config::Std, the write_config() method that it imported > overrode the base class implementation. Needless to say, these are > not the same kinds of functions at all. > > To get around this, for now, I'm calling the Config::Std functions > directly: > > use Config::Std (); > ... > Config::Std::Hash::read_config($conf_file => my %conf); > ... > Config::Std::Hash::write_config(%conf); > > I'm uncomfortable with this approach because these functions are not > documented.
Huh? They're exactly the same subroutines, with exactly the same name. The only difference being that you've elected to name them using their fully qualified names, rather than the short-hand names the module's export mechanism provides. This is a very standard thing to do in Perl. I don't believe it requires explicit documentation, or a special renaming mechanism. Show quoted text
> 2. Allow the names of the functions to be imported to be modified
Again, there's already a standard aliasing mechanism for that in Perl: use Config::Std (); *cs_read_config = *Config::Std::Hash::read_config; *cs_write_config = *Config::Std::Hash::write_config; No special mechanism is needed. Damian
Subject: Re: [rt.cpan.org #16804] Re: [cpan #16804] No Import Conflict Handling
Date: Thu, 9 Feb 2006 15:23:33 -0800
To: bug-Config-Std [...] rt.cpan.org
From: David Wheeler <david [...] kineticode.com>
On Feb 9, 2006, at 15:20, damian@conway.org via RT wrote: Show quoted text
> Huh? They're exactly the same subroutines, with exactly the same name. > The only difference being that you've elected to name them using their > fully qualified names, rather than the short-hand names the module's > export mechanism provides. > > This is a very standard thing to do in Perl. I don't believe it > requires > explicit documentation, or a special renaming mechanism.
Well, it does, because Config::Std::Hash is not documented, so when one tries to use Config::Std::config() and gets an error, it can seem rather mysterious. Show quoted text
>
>> 2. Allow the names of the functions to be imported to be modified
> > Again, there's already a standard aliasing mechanism for that in Perl: > > use Config::Std (); > *cs_read_config = *Config::Std::Hash::read_config; > *cs_write_config = *Config::Std::Hash::write_config; > > No special mechanism is needed.
Yes, but again, since Config::Std::Hash is not documented, one has to look at the source to figure out how to do that. I suggested the alternative in case you didn't want to add read_confg() and write_config() functions do the Config::Std namespace, or in case you didn't want to document Config::Std::Hash. Best, David
Subject: Re: [rt.cpan.org #16804] Re: [cpan #16804] No Import Conflict Handling
Date: Fri, 10 Feb 2006 10:51:06 +1100
To: bug-Config-Std [...] rt.cpan.org
From: Damian Conway <damian [...] conway.org>
Okay, David. Now I see your point...and agree with it. Seems like the best solution is to provide a rename-on-export mechanism, as you suggested. See the attached beta. Damian

Message body is not shown because sender requested not to inline it.

Subject: Re: [rt.cpan.org #16804] Re: [cpan #16804] No Import Conflict Handling
Date: Thu, 9 Feb 2006 16:03:43 -0800
To: bug-Config-Std [...] rt.cpan.org
From: David Wheeler <david [...] kineticode.com>
On Feb 9, 2006, at 15:52, damian@conway.org via RT wrote: Show quoted text
> Okay, David. Now I see your point...and agree with it. > > Seems like the best solution is to provide a rename-on-export > mechanism, as you suggested. See the attached beta.
Works great for me, thanks. Dunno if this was reported elsewhere (if not, I'll be glad to), but is there anyway to eliminate the warnings from Class::Std when I load Config::Std at run time (e.g., via require or under mod_perl)? I know it has been reported for Class::Std, but naturally it affects Config::Std, too. Thanks, David
Subject: Re: [rt.cpan.org #16804] Re: [cpan #16804] No Import Conflict Handling
Date: Fri, 10 Feb 2006 13:10:00 +1100
To: bug-Config-Std [...] rt.cpan.org
From: Damian Conway <damian [...] conway.org>
David Wheeler via RT wrote: Show quoted text
> Dunno if this was reported elsewhere (if not, I'll be glad to), but > is there anyway to eliminate the warnings from Class::Std when I load > Config::Std at run time (e.g., via require or under mod_perl)? I know > it has been reported for Class::Std, but naturally it affects > Config::Std, too.
Sorry, David, I don't have a work-around for that. I'm not sure one's even possible. I consider it a flaw in perl itself that CHECK blocks aren't always run when code is compiled. I've reported that to P5P. Damian
Subject: Re: [rt.cpan.org #16804] Re: [cpan #16804] No Import Conflict Handling
Date: Thu, 9 Feb 2006 18:32:51 -0800
To: bug-Config-Std [...] rt.cpan.org
From: David Wheeler <david [...] kineticode.com>
On Feb 9, 2006, at 18:11, damian@conway.org via RT wrote: Show quoted text
> Sorry, David, I don't have a work-around for that. I'm not sure one's > even possible. I consider it a flaw in perl itself that CHECK blocks > aren't always run when code is compiled. I've reported that to P5P.
I do, too, but we both know that's not going to change in Perl 5, yes? What about creating a separate method and asking module authors to call it separately, instead of relying on CHECK magic? Best, David
Subject: Re: [rt.cpan.org #16804] Re: [cpan #16804] No Import Conflict Handling
Date: Fri, 10 Feb 2006 13:56:15 +1100
To: bug-Config-Std [...] rt.cpan.org
From: Damian Conway <damian [...] conway.org>
David Wheeler via RT wrote: Show quoted text
> What about creating a separate method and asking module authors > to call it separately, instead of relying on CHECK magic?
"asking module authors to..." is a recipe for instant unreliability. ;-) Therefore, the next version of Class::Std will have a work-around. From the new docs: Non-exported subroutines Class::Std::initialize() This subroutine sets up all the infrastructure to support your Class::Std-based class. It is usually called automatically in a "CHECK" block, or (if the "CHECK" block fails to run -- under "mod_perl" or "require Class::Std" or "eval "..."") during the first constructor call made to a Class::Std-based object. In rare circumstances, you may need to call this subroutine directly yourself. Specifically, if you set up cumulative, restricted, private, or automethodical class methods (see below), and call any of them before you create any objects, then you need to call "Class::Std::initialize()" first. That will solve the problem without relying on module authors being reliable, whilst still allowing them to be reliable, if they're capable of it. ;-) And I've also managed to make it silence the CHECK warning. Give the attached beta a try and see if it works for you (it contains many other changes too, so you might want to glance through the POD as well). Damian

Message body is not shown because it is too large.

Subject: Re: [rt.cpan.org #16804] Re: [cpan #16804] No Import Conflict Handling
Date: Fri, 10 Feb 2006 12:25:28 -0800
To: bug-Config-Std [...] rt.cpan.org
From: David Wheeler <david [...] kineticode.com>
On Feb 9, 2006, at 18:58, damian@conway.org via RT wrote: Show quoted text
> "asking module authors to..." is a recipe for instant > unreliability. ;-)
True. But it would be more reliable than just depending on CHECK, since CHECK doesn't run at all in certain contexts. Show quoted text
> Therefore, the next version of Class::Std will have a work-around. > From > the new docs:
<snip/> Show quoted text
> That will solve the problem without relying on module authors being > reliable, whilst still allowing them to be reliable, if they're > capable > of it. ;-) And I've also managed to make it silence the CHECK warning.
Sweet! Show quoted text
> Give the attached beta a try and see if it works for you (it > contains many other changes too, so you might want to glance through > the POD as well).
Seems to work for me. A simple script with nothing but require Config::Std; ...no longers issues a warning. So, when will these new versions of Class::Std and Config::Std be released? Thanks! David