Re^5: stronger than eval?

if the method is called use or require, then yes, i am ok with that, even when it results in dying if you try $obj->use because you did not define your own use method on that class (which is what would typically happen anyway, except with a different error).

the more exceptional case would be when you expected to handle use or require methods via AUTOLOAD, but i would never expect such so adding these methods to UNIVERSAL is ok with me.

Comment on Re^5: stronger than eval? Select or Download Code

Replies are listed 'Best First'.
Re^6: stronger than eval? by perrin (Chancellor) on Sep 21, 2006 at 20:19 UTC
I have to agree with diotalevi on this: there is no good reason for this to be done through UNIVERSAL::. It's just a simple utility method. It does not need to be added to every namespace automatically.	[reply]
Re^7: stronger than eval? by ikegami (Patriarch) on Sep 21, 2006 at 21:57 UTC
I agree too. For example, `use UNIVERSAL::require (); Cache::File->use() or print "error: $@";` [download] could be written as `use Module::Loader qw( load ); load Cache::File or print "error: $@";` [download] Just as readable. Just as simple. No polution of `UNIVERSAL::`. And with the right prototype, `load`'s argument doesn't even need to be quoted. Update: The module I made up above already exists as Module::Load! Update: Module::Load dies instead of returning false.	[reply] [d/l] [select]
Re^6: stronger than eval? by diotalevi (Canon) on Sep 21, 2006 at 20:13 UTC
Ok, fine, I guess. What's also missing is that there's no need to implement this with UNIVERSAL:: pollution. This could have just been a "smarter" use and require function named something appropriate and it wouldn't have caused issues for other objects. I have sympathy for features that are best (or perhaps only) implemented by polluting UNIVERSAL:: but this isn't one of them. ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊	[reply]