Skip Menu |

This queue is for tickets about the UNIVERSAL-require CPAN distribution.

Report information
The Basics
Id: 24741
Status: open
Priority: 0/
Queue: UNIVERSAL-require

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

Bug Information
Severity: Normal
Broken in:
  • 0.10
  • 0.11
Fixed in: (no value)



Subject: simple change allow custom $Level so modules can use use() to import into its caller()
I stumbled across your module and think its a great idea! Thanks for it :) I have a couple projects that I'd like tp use it on but currently have to edit require.pm in this way: in 'sub use' change local $Level = 1; to local $Level = $Level ? $Level : 1; and it works as it does now except expands possibilities.
From: MSCHWERN [...] cpan.org
On Fri Feb 02 13:38:55 2007, DMUEY wrote: Show quoted text
> I stumbled across your module and think its a great idea! Thanks for > it :) > > I have a couple projects that I'd like tp use it on but currently have > to edit require.pm in this > way: > > in 'sub use' > > change > local $Level = 1; > to > local $Level = $Level ? $Level : 1; > > and it works as it does now except expands possibilities.
Sorry, this must have come in while rt.cpan.org wasn't sending out mail and I didn't notice it. Rather than exposing an already hacky global, it would be better to allow the user to pass in the level, or rather the explicit package name, to export to. If it were any other module I'd say to add something like use_in_package(), but I'm loathe to add a new method to UNIVERSAL--especially one which is not a core keyword which anyone else is unlikely to define. There's not much space in the UNIVERSAL::require->use() interface to wedge in the package name. It also runs the problem of making the arguments to use() different from CORE::use.
From: DMUEY [...] cpan.org
Show quoted text
> Sorry, this must have come in while rt.cpan.org wasn't sending out mail > and I didn't notice it.
No worries :) Show quoted text
> Rather than exposing an already hacky global, it would be better to > allow the user to pass in the level, or rather the explicit package > name, to export to. If it were any other module I'd say to add > something like use_in_package(), but I'm loathe to add a new method to > UNIVERSAL--especially one which is not a core keyword which anyone else > is unlikely to define.
I agree on both points. Show quoted text
> There's not much space in the UNIVERSAL::require->use() interface to > wedge in the package name. It also runs the problem of making the > arguments to use() different from CORE::use.
I agree with that also, which makes the simple change pretty much the only option :) See how I used it in http://search.cpan.org/src/DMUEY/first-v0.0.1/lib/first.pm Its already starting at 0 and can be changed for require() ( require() does not local()ize it but use() does...) They should both do the: local $Level = $Level ? $Level : $default_value_for_this_method_goes_here_instead_of_variabe; To allow a user to specify it for both and for both to act consistently Also what about having: $UNIVERSAL::require::require_level = 0; $UNIVERSAL::require::use_level = 1; Then in require() local $UNIVERSAL::require::require_level = int $UNIVERSAL::require::require_level ? int $UNIVERSAL::require::require_level : 0; and in use () local $UNIVERSAL::require::use_level = int $UNIVERSAL::require::use_level ? int $UNIVERSAL::require::use_level : 1; local $UNIVERSAL::require::require_level = $UNIVERSAL::require::use_level; That way: - they have fine grained control over require and use if they do not want the default behavior - they use the method specific defaults - they no longer use a global UNIVERSAL:: var but rather UNIVERSAL::require:: global - keeps same args to UNIVERSAL->use() as use() - no need for use_at_this_level() or use_at_this_namespace() methods in UNIVERSAL:: - use() setting of it will propgate to its require() call as needed Wadda ya think?