Bug #53683 for UNIVERSAL-require: require() should be chainable

Thu Jan 14 09:08:22 2010 RKINYON [...] cpan.org - Ticket created

Subject:

require() should be chainable

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.

Thu Jan 14 15:41:28 2010 schwern [...] pobox.com - Correspondence added

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>

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!

Thu Jan 14 15:41:30 2010 The RT System itself - Status changed from 'new' to 'open'

Thu Jan 14 15:46:02 2010 RKINYON [...] cpan.org - Correspondence added

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?

Thu Jan 14 17:07:59 2010 schwern [...] pobox.com - Correspondence added

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>

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/

Thu Jan 14 17:13:34 2010 RKINYON [...] cpan.org - Correspondence added

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.

Thu Jan 14 19:27:57 2010 schwern [...] pobox.com - Correspondence added

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>

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

Thu Jan 14 20:43:57 2010 RKINYON [...] cpan.org - Correspondence added

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!