On 8 December 2016 at 12:31, Sawyer X <xsawyerx@gmail.com> wrote: > I think good points we made here. My position is also wishing to avoid > adding modules. Modules I would consider are such that solve a common > basic problem, have little opinion, and a great net-gain across the > board of users. This is why I threw Module::Runtime into this. > > Now, having said that, the comments were very useful and I appreciate > them and agree with them. I agree with Vincent's summary of having one > good loader in core instead of multiple ones. > > I would like to then ask the following question: How plausible is it to > "fix" Module::Load, considering people might expect its heuristic behavior? Adding a simple load_module() (or load_class) function to Module::Load that would always: - interpret its argument as a module/class name - load the module and return true or die trying would, in my opinion, go a long way in removing the need for other modules. Having try_load_module a la Class::Load might be nice too but much less important. Wrapping a try or eval around load_module() is much less of a hassle than having to fiddle with path seperators and .pm extensions. Importing stuff is not really important either in my view. You can always say $class->import() and I suspect dynamically loading modules is mostly used for classes that don't export anything anyway... I wouldn't worry about supporting barewords either. I'm totally fine using use or require for barewords and load_module for dynamic class names. The most important thing is to have a simple, sane, available function for loading modules dynamically, that doesn't do weird heuristics and guessing games. /L > On 12/06/2016 11:21 PM, Vincent Pit (VPIT) wrote: >> >>> >>> If anything, I'd lean towards fixing Module::Load, if only because we >>> actually have other modules in core that already depend on it (mostly >>> via Module::Load::Conditional). >>> >> >> This is my opinion as well. >> >> Compared to Module::Load, Module::Runtime has a couple of extra >> workarounds for bugs in pre-5.12 perls that can be easily ported if >> deemed acceptable with regards to compatibility. Module::Rutime's >> interface is generally better, but the relevant alternate interfaces >> could be added to Module::Load. >> >> Let's just focus in having one good loader in core, that's less >> maintenance in the long run, and more user-friendly. >> >> >> Vincent >Thread Previous | Thread Next