Skip Menu |
 

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

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

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

Bug Information
Severity: Important
Broken in: 0.13
Fixed in: (no value)



Subject: require() should be chainable
Download (untitled) / with headers
text/plain 226b
I've found myself wanting to be able to do: $module->require->new( @args ); Instead of return $return at the end of require(), return $module would be nice. I suppose making that change to use() would probably be good, too.
Subject: Re: [rt.cpan.org #53683] require() should be chainable
Date: Thu, 14 Jan 2010 12:40:58 -0800
To: bug-UNIVERSAL-require [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Download (untitled) / with headers
text/plain 558b
RKINYON via RT wrote: Show quoted text
> I've found myself wanting to be able to do: > > $module->require->new( @args ); > > Instead of return $return at the end of require(), return $module would be nice. I suppose > making that change to use() would probably be good, too.
Interesting idea, but its saving you just typing "$module". This would leave you unable to check for the failure of require() or the return value of require. It will probably fail at the call to new(), but with an ugly error message. -- Whip me, beat me, make my code compatible with VMS!
Download (untitled) / with headers
text/plain 739b
On Thu Jan 14 15:41:28 2010, schwern@pobox.com wrote: Show quoted text
> RKINYON via RT wrote:
> > I've found myself wanting to be able to do: > > > > $module->require->new( @args ); > > > > Instead of return $return at the end of require(), return $module
> would be nice. I suppose
> > making that change to use() would probably be good, too.
> > Interesting idea, but its saving you just typing "$module". > > This would leave you unable to check for the failure of require() or > the > return value of require. It will probably fail at the call to new(), > but with > an ugly error message.
require() should be dying if it fails, so error-checking should be via eval {}. That leaves the actual return value to be useful in other ways, wouldn't it?
Subject: Re: [rt.cpan.org #53683] require() should be chainable
Date: Thu, 14 Jan 2010 14:07:39 -0800
To: bug-UNIVERSAL-require [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Download (untitled) / with headers
text/plain 748b
RKINYON via RT wrote: Show quoted text
>> This would leave you unable to check for the failure of require() or >> the >> return value of require. It will probably fail at the call to new(), >> but with >> an ugly error message.
> > require() should be dying if it fails
UNIVERSAL::require's require() does not. You're right, it SHOULD, but it doesn't. Irreversible design flaw. :( Show quoted text
> so error-checking should be via eval {}. That leaves the > actual return value to be useful in other ways, wouldn't it?
-- 39. Not allowed to ask for the day off due to religious purposes, on the basis that the world is going to end, more than once. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
Download (untitled) / with headers
text/plain 594b
On Thu Jan 14 17:07:59 2010, schwern@pobox.com wrote: Show quoted text
> RKINYON via RT wrote:
> >> This would leave you unable to check for the failure of require() or > >> the > >> return value of require. It will probably fail at the call to new(), > >> but with > >> an ugly error message.
> > > > require() should be dying if it fails
> > UNIVERSAL::require's require() does not. You're right, it SHOULD, but it > doesn't. Irreversible design flaw. :(
Not irreversible. IO::All provides for a -strict option. No reason UNIVERSAL::require couldn't do the same. That would promote all errors to dies.
Subject: Re: [rt.cpan.org #53683] require() should be chainable
Date: Thu, 14 Jan 2010 16:27:33 -0800
To: bug-UNIVERSAL-require [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Download (untitled) / with headers
text/plain 743b
RKINYON via RT wrote: Show quoted text
> Not irreversible. IO::All provides for a -strict option. No reason UNIVERSAL::require couldn't do > the same. That would promote all errors to dies.
This is true, and I did do some work to add a "die" option, but at this point, honestly, Module::Load is a better option. That you're going to load UNIVERSAL::require once and then rely on it being loaded outside that context is not very safe. You might as well import a function, not have to use a special switch and not pollute UNIVERSAL. I'm pretty much done with the module. If you want to continue its development I'll gladly transfer ownership. -- Don't try the paranormal until you know what's normal. -- "Lords and Ladies" by Terry Prachett
Download (untitled) / with headers
text/plain 856b
On Thu Jan 14 19:27:57 2010, schwern@pobox.com wrote: Show quoted text
> RKINYON via RT wrote:
> > Not irreversible. IO::All provides for a -strict option. No reason
> UNIVERSAL::require couldn't do
> > the same. That would promote all errors to dies.
> > This is true, and I did do some work to add a "die" option, but at > this point, > honestly, Module::Load is a better option. That you're going to load > UNIVERSAL::require once and then rely on it being loaded outside that > context > is not very safe. You might as well import a function, not have to > use a > special switch and not pollute UNIVERSAL.
I had looked at Module::Load when evaluating UNIVERSAL::require. Show quoted text
> I'm pretty much done with the module. If you want to continue its > development > I'll gladly transfer ownership.
If you're deprecating this module, I'll just switch to that one. Thanks!


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.