develooper Front page | perl.perl5.porters | Postings from September 2022

Re: module loading built-in

Thread Previous | Thread Next
Darren Duncan
September 17, 2022 22:07
Re: module loading built-in
Message ID:
On 2022-09-17 2:29 p.m., demerphq wrote:
> On Sat, 17 Sept 2022, 21:31 Darren Duncan wrote:
>     On 2022-09-17 7:02 a.m., demerphq wrote:
>      > So all I see is a bunch of folks sticking this load function in an eval.
>     I interpret this that you see many people not understanding how to use the new
>     function properly and that they incorrectly assume they have to put it in an
>     eval to make it work like "require $foo" etc.  So that's up to education.
> Er, no. It's a direct consequence of Paul's comment that load should die if it 
> fails. I start to get the impression you folks advocating for this aren't on the 
> same page with each other.

There is no conflict here because I assume there would be multiple versions of 
the functionality and users can pick the version that does or doesn't die on 
failure depending on what they want.

>     A key usage scenario I see for these new methods is when we have a library with
>     a plugin architecture such that the specific plugin module we want to use is
>     not
>     known except at runtime and it is a user configuration data file etc that is
>     naming the module to use.
> This is exactly the kind of antipattern I object to in a library and exactly the 
> kind of thing that if you are doing performance sensitive multi process stuff 
> that causes serious problems and is pretty much exactly a description of the 
> kind of problem I'd like to see solved.

I'm not saying a plugin architecture is always appropriate, but there are 
legitimate reasons for a core tool to not have to have knowledge of every 
third-party thing that might be used with it.

Why should Adobe Photoshop ship with a list of all the possible third-party 
plugins baked into its source code?

>     For example, it would be a cleaner way to implement something like the DBI
>     module which can use the new methods to load any DBMS driver module the user
>     names via connect().
> I don't consider that good practice so it doesnt really sell me. If you are 
> using a specific dbd then use it. Sql isn't that portable and DBIs abstraction 
> does not insulate you from the portability issues that come from SQL.

I actually agree with you, and feel that DBI's design is backwards.  Instead a 
better design is that DBI is just an interface definition that each database 
driver adopts, and that users should just be using the driver module directly, 
eg they say "use DBD::Oracle" and "DBD::Oracle->connect()" or whatever.

And despite appearances, DBI is actually worse because it actually does have 
intimate knowledge of possible drivers, a list of such baked into its source 
code, or it did last I looked.

However, I raised this as a well known example of a plugin architecture.

>     For another example, it would be a cleaner way to implement localization type
>     modules that implement each user language as a Perl module, an example being my
>     Locale::KeyedText module on CPAN.
>     With the new builtins available, I wouldn't have to resort to these shenanigans:
> This just looks like bad api design to me. If I needed something like that I'd 
> ensure there is a well defined method to call in the module that returned a list 
> of whatever was needed. Introspecting on the package stash doesn't prove 
> anything. Anybody can do 'sub Module::thing {}' anywhere and break this logic.
>   I don't see how it relates to having a load builtin either. Loading package 
> foo doesn't mean that any code will end up in the foo namespace. Package foo can 
> populate any or no namespaces. Package names and stashes are only coincidentally 
> related to each other, and are not necessarily related.
> I've done things like this, but I''d never touch $@ without a false return from 
> an eval. Even if it might work in modern perls it's just confusing to newbies. 
> Treating $@ like $! Is good practice. I've seen maintainer coders stick 
> arbitrary code in between the eval and $@ access, which as $@ is volatile can 
> completely change the result. I'd consider that a bug waiting to happen if it 
> were in a communal code base.
> So, it's not clear to me what you expect. At the start of this mail you 
> suggested that the proposed builtin would not need an eval, but here you gave a 
> function that rethrows the exception and would require an eval if I 
> speculatively want to load something, a pattern which I have seen far more than 
> the cases you describe. Eg "use this module and if it's present import a sub, 
> and if it's not use a roll-your-own replacement".

My mentioning Locale::KeyedText was just meant to be another example of how 
checking for the use of a package use or loading one is much more contrived than 
it ought to be.  The fact that I happen to throw an exception on failure is 
beside the point.

Also, Locale::KeyedText is an old CPAN module I no longer update or expect 
anyone to use, and it doesn't reflect the latest good design.  It was based on 
trying to make available the MacOS feature of externally installable language 
resources for applications where no language is privileged over others, eg no 
replacing English text with other languages.

> So does this proposed new function die if it fails to load or not?

I assume there would be multiple versions so users can choose.

The whole proposal is for a set of routines, not just one.

-- Darren Duncan

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About