Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modernize Exporter usage in perlmod #16879

Closed
p5pRT opened this issue Mar 8, 2019 · 23 comments
Closed

Modernize Exporter usage in perlmod #16879

p5pRT opened this issue Mar 8, 2019 · 23 comments

Comments

@p5pRT
Copy link

p5pRT commented Mar 8, 2019

Migrated from rt.perl.org#133909 (status was 'resolved')

Searchable as RT133909$

@p5pRT
Copy link
Author

p5pRT commented Mar 8, 2019

From @Grinnz

perlmod contains a "module template" which shows outdated usage of the
Exporter module. The attached patch will modernize it, both by simply
importing the 'import' method instead of inheriting from Exporter, and
removing the $VERSION and @​EXPORT/_OK declarations from the BEGIN block as
they are not required to be instantiated at the module's compile time. This
will more closely match the appearance of most similar modules on CPAN.

-Dan

(Perl)

@p5pRT
Copy link
Author

p5pRT commented Mar 8, 2019

From @Grinnz

Patch is attached.

@p5pRT
Copy link
Author

p5pRT commented Mar 8, 2019

From @Grinnz

0001-modernize-Exporter-usage-in-perlmod-module-template.patch
From 8bae8c75e89dc50c6bd1ef0e36795626b6bdc009 Mon Sep 17 00:00:00 2001
From: Dan Book <grinnz@grinnz.com>
Date: Thu, 7 Mar 2019 19:34:14 -0500
Subject: [PATCH] modernize Exporter usage in perlmod module template

---
 pod/perlmod.pod | 22 +++++++++-------------
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/pod/perlmod.pod b/pod/perlmod.pod
index c87a68d837..ffabe94b5d 100644
--- a/pod/perlmod.pod
+++ b/pod/perlmod.pod
@@ -447,21 +447,17 @@ create a file called F<Some/Module.pm> and start with this template:
     use strict;
     use warnings;
 
-    BEGIN {
-        require Exporter;
+    # Get the import method from Exporter to export functions and variables
+    use Exporter 'import';
 
-        # set the version for version checking
-        our $VERSION     = 1.00;
+    # set the version for version checking
+    our $VERSION     = 1.00;
 
-        # Inherit from Exporter to export functions and variables
-        our @ISA         = qw(Exporter);
+    # Functions and variables which are exported by default
+    our @EXPORT      = qw(func1 func2);
 
-        # Functions and variables which are exported by default
-        our @EXPORT      = qw(func1 func2);
-
-        # Functions and variables which can be optionally exported
-        our @EXPORT_OK   = qw($Var1 %Hashit func3);
-    }
+    # Functions and variables which can be optionally exported
+    our @EXPORT_OK   = qw($Var1 %Hashit func3);
 
     # exported package globals go here
     our $Var1    = '';
@@ -487,7 +483,7 @@ create a file called F<Some/Module.pm> and start with this template:
     sub func1      { ... }
     sub func2      { ... }
 
-    # this one isn't exported, but could be called directly
+    # this one isn't always exported, but could be called directly
     # as Some::Module::func3()
     sub func3      { ... }
 
-- 
2.20.1

@p5pRT
Copy link
Author

p5pRT commented Mar 8, 2019

From @Grinnz

Updated patch. Additionally changes the version declaration to be a string.

@p5pRT
Copy link
Author

p5pRT commented Mar 8, 2019

From @Grinnz

0001-modernize-Exporter-usage-in-perlmod-module-template.patch
From 0e175824dce34de2853b69e1c4e5cccb2924e187 Mon Sep 17 00:00:00 2001
From: Dan Book <grinnz@grinnz.com>
Date: Thu, 7 Mar 2019 19:34:14 -0500
Subject: [PATCH] modernize Exporter usage in perlmod module template

---
 pod/perlmod.pod | 22 +++++++++-------------
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/pod/perlmod.pod b/pod/perlmod.pod
index c87a68d837..64d5fdd81a 100644
--- a/pod/perlmod.pod
+++ b/pod/perlmod.pod
@@ -447,21 +447,17 @@ create a file called F<Some/Module.pm> and start with this template:
     use strict;
     use warnings;
 
-    BEGIN {
-        require Exporter;
+    # Get the import method from Exporter to export functions and variables
+    use Exporter 'import';
 
-        # set the version for version checking
-        our $VERSION     = 1.00;
+    # set the version for version checking
+    our $VERSION     = '1.00';
 
-        # Inherit from Exporter to export functions and variables
-        our @ISA         = qw(Exporter);
+    # Functions and variables which are exported by default
+    our @EXPORT      = qw(func1 func2);
 
-        # Functions and variables which are exported by default
-        our @EXPORT      = qw(func1 func2);
-
-        # Functions and variables which can be optionally exported
-        our @EXPORT_OK   = qw($Var1 %Hashit func3);
-    }
+    # Functions and variables which can be optionally exported
+    our @EXPORT_OK   = qw($Var1 %Hashit func3);
 
     # exported package globals go here
     our $Var1    = '';
@@ -487,7 +483,7 @@ create a file called F<Some/Module.pm> and start with this template:
     sub func1      { ... }
     sub func2      { ... }
 
-    # this one isn't exported, but could be called directly
+    # this one isn't always exported, but could be called directly
     # as Some::Module::func3()
     sub func3      { ... }
 
-- 
2.20.1

@p5pRT
Copy link
Author

p5pRT commented Mar 8, 2019

From @jkeenan

On Fri, 08 Mar 2019 00​:42​:30 GMT, grinnz@​gmail.com wrote​:

Updated patch. Additionally changes the version declaration to be a string.

+1

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented Mar 8, 2019

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Mar 8, 2019

From @Leont

On Fri, Mar 8, 2019 at 1​:43 AM Dan Book via RT
<perlbug-followup@​perl.org> wrote​:

Updated patch. Additionally changes the version declaration to be a string.

Importing Exporter​::import requires Exporter 5.57, I would make that
dependency explicit.

Leon

@p5pRT
Copy link
Author

p5pRT commented Mar 8, 2019

From @xenu

On Fri, 8 Mar 2019 14​:32​:16 +0100
Leon Timmermans <fawaka@​gmail.com> wrote​:

Importing Exporter​::import requires Exporter 5.57, I would make that
dependency explicit.

Leon

Which was released billion years ago. Perl 5.8.3 was the first perl to
ship with 5.57, which means it's *extremely* unlikely that anyone will
run into a version of Exporter that doesn't support it.

IMO at this point this information is a historical trivia and it doesn't
belong in perl 5.30 documentation.

@p5pRT
Copy link
Author

p5pRT commented Mar 9, 2019

From Vadim.Konovalov@dell.com

On Fri, 8 Mar 2019 14​:32​:16 +0100
Leon Timmermans wrote​:

Importing Exporter​::import requires Exporter 5.57, I would make that
dependency explicit.

Leon

Which was released
billion years ago. Perl 5.8.3 was the first perl to ship with 5.57, which means
it's *extremely* unlikely that anyone will run into a version of Exporter that
doesn't support it.

then perl is so ancient that it have no chances to modernize, ever!.

Observe​:

perldoc perlvar

...

  Since Perl v5.6.0, Perl variable names may also be alphanumeric strings preceded by a caret. These must all be
  written in the form "${^Foo}"; the braces are not optional. "${^Foo}" denotes the scalar variable whose name is

...

what is this? 5.8.3 is billion years? but documentation cares of 5.6.0??
what ancient thing is this??

maaaan, need to switch to modern something!

@p5pRT
Copy link
Author

p5pRT commented Mar 9, 2019

From @Tux

On Sat, 9 Mar 2019 13​:31​:18 +0000, "Konovalov, Vadim" <Vadim.Konovalov@​dell.com> wrote​:

On Fri, 8 Mar 2019 14​:32​:16 +0100
Leon Timmermans wrote​:

Importing Exporter​::import requires Exporter 5.57, I would make
that dependency explicit.

Leon

Which was released billion years ago. Perl 5.8.3 was the first perl
to ship with 5.57, which means it's *extremely* unlikely that
anyone will run into a version of Exporter that doesn't support it.

then perl is so ancient that it have no chances to modernize, ever!.

Observe​:

perldoc perlvar

...
Since Perl v5.6.0, Perl variable names may also be alphanumeric
strings preceded by a caret. These must all be written in the form
"${^Foo}"; the braces are not optional. "${^Foo}" denotes the scalar
variable whose name is
...

what is this? 5.8.3 is billion years?

$ perldoc perlhist

will show you

5.8.3 2004-Jan-14

Diff : 5533 days (15 y, 1 m, 23 d)
Not even close to a billion, not even in days, not even in seconds
(478051200). If I'm correct that is half a billion.

but documentation cares of 5.6.0?? what ancient thing is this??

5.6.0 2000-Mar-22

Diff : 6926 days (18 y, 11 m, 15 d)

maaaan, need to switch to modern something!

perl *is* modern, but - in contradiction with some other languages -
perl cares *a lot* about backward compatibility.

There is no harm whatsoever in mentioning in the docs why the current
version is better than an historic version. Note that 5.6.2 (and
probably some older versions too) are still used in production.
Sometimes the reasons to use those archaic versions are not within perl
itself, but in the software that uses it, and is not maintained
anymore. Same goes for operating systems. I know of systems that still
run HP-UX 10.20 as production base, just because the dedicated software
the (Italian) company relies on does not run on anything else. So there
the language is old, the OS is old, and the application is old, but it
still makes them earn their money.

So, with that in mind, can you tell me why it hurts you to be explicit
in requiring a specific version of software that still runs, is fully
functional and makes people earn their living?

Being specific in what you require does not slow down the process, it
just adds to the clarity.

Maybe you also use C++-style comments instead of ANSI-C style comments,
just because GNU gcc accepts that for deity knows how long. Not all
compilers are C99, and even if they claim to be, they quite often are
not. How hard is it to just stick to something that is *also* supported
in software that was created ages ago, but is still in use? It does not
harm the code itself. At all.

FWIW, unless it really hinders my development, I still try to support
the oldest perl release I can check. e.g. Text​::CSV_XS still works on
5.6.0, and I check that before every release.

If you want to switch to something more modern, switch to perl-5.28.1
or perl6 and ignore all references to old (in your view) cruft and use
all features that are available in these wonderful languages! You are
not forced to support old(er) versions of perl if you don't want to.

--
H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/
using perl5.00307 .. 5.29 porting perl5 on HP-UX, AIX, and openSUSE
http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/
http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

@p5pRT
Copy link
Author

p5pRT commented Mar 9, 2019

From @Grinnz

This is not reference documentation. This is a tutorial for how to write new modules, and displays a template which is highly likely to be copy pasted around without further inspection. Any extraneous information is likely to be ignored or cause further confusion. I would consider the exporting of non-sub variables to be extraneous as well in the context of what new module writers need, but that is out of the scope of this patch. If a user wants to support ancient Perls, they can read the linked docs for Exporter to determine how to do so.

-Dan

@p5pRT
Copy link
Author

p5pRT commented Mar 10, 2019

From Vadim.Konovalov@dell.com

Which was released billion years ago. Perl 5.8.3 was the first perl
to ship with 5.57, which means it's *extremely* unlikely that anyone
will run into a version of Exporter that doesn't support it.
Diff : 5533 days
(15 y, 1 m, 23 d)
Not even close to a billion, not even in days, not even in
seconds (478051200). If I'm correct that is half a billion.

q.e.d.
" billion years ago " is not correct

perl *is* modern, but - in contradiction with some other
languages - perl cares *a lot* about backward compatibility.

this is so, I agree.
But when it comes to actual break of old code (#127512) - then my old code was declared
wrong rather than caring about actual compatibility

There is no harm
whatsoever in mentioning in the docs why the current version is better than an
historic version. Note that 5.6.2 (and probably some older versions too) are
still used in production.

In current IT standards they will say to you that old versions are vulnerable to hacker attacks
(I hate this argumentation)

Sometimes the reasons to use those archaic versions
are not within perl itself, but in the software that uses it, and is not
maintained anymore. Same goes for operating systems. I know of systems that
still run HP-UX 10.20 as production base, just because the dedicated software
the (Italian) company relies on does not run on anything else. So there the
language is old, the OS is old, and the application is old, but it still makes
them earn their money.

So, with that in mind, can you tell me why it hurts you
to be explicit in requiring a specific version of software that still runs, is
fully functional and makes people earn their living?

It occupies 2 expensive things​: engineer's time on reading this documentation and
screen space.

However I raised this problem, couple of times, couple of years ago, so returning
to this again isn't productive, so let be things as they now are :)

not a big deal, anyway

Being specific in what
you require does not slow down the process, it just adds to the clarity.

It does slow down, strictly speaking. It could be that slowing down the process is so small
that it is unnoticeable.

Vadim

@p5pRT
Copy link
Author

p5pRT commented Apr 8, 2019

From @xsawyerx

On 3/8/19 3​:32 PM, Leon Timmermans wrote​:

On Fri, Mar 8, 2019 at 1​:43 AM Dan Book via RT
<perlbug-followup@​perl.org> wrote​:

Updated patch. Additionally changes the version declaration to be a string.

Importing Exporter​::import requires Exporter 5.57, I would make that
dependency explicit.

From my perspective, there are several alternatives, of which I don't
particularly favor either - they're all fine by me.

1. Update it to `use Exporter 5.57;` and be done with it.

2. Update it to `use Exporter;` and the line below would be something
like `# or​: use Exporter 5.57; if you want to verify you have the
minimal required version`.

2. Don't update it to 5.57, but write a paragraph underneath saying
"This requires Exporter 5.57, released in X. If you are using an older
version of Perl and cannot upgrade Exporter, here's what you want."

3. Don't update it to 5.57, but include a small sentence saying "This
requires Exporter 5.57. If you are using an older version, please see
Exporter documentation or the Perl documentation for your Perl version."

The argument here is simple​:

* Short, clear examples are easier to read and understand.

* Do not optimize for *all* use-cases, but for the most common ones.

* If you're using something old enough[1] that does not carry this
version, you are far less likely to be looking at new documentation
anyway. You are also less likely to be developing new software. See
previous clause.

* You can always find the old documentation that came with your Perl and
it will be *far* more accurate for what you are doing than the most
recent one.

* The only argument here against the patch falls into "don't do it,"
because adding the version does not fix the problem of someone not
carrying it, only blocks it in a more visible way. I agree we should
modernize the docs.

Theoretically, we would like our documentation to reflect the supported
versions and the best coding patterns. In practice, we will cover more
than the supported versions since we would prefer to adhere to "used
versions," but Perl being Perl this strict definition would include
*way* more versions than we care to support and carry these patterns to
new users. So, I suggest "most used versions" or "commonly used
versions." (Let's not open this to a discussion of semantics on specific
wording. I think my intent here is clear.) (And yes, "best practices" is
the most debated term in Perl, but let's not get trapped there.)

S.

[1] Without going into the argument of "this is ancient" or what the
definition of "billions" is.

@p5pRT
Copy link
Author

p5pRT commented Apr 8, 2019

From @demerphq

On Mon, 8 Apr 2019 at 07​:47, Sawyer X <xsawyerx@​gmail.com> wrote​:

[1] Without going into the argument of "this is ancient" or what the
definition of "billions" is.

There are two definitions of "billion". Which one did you not want to
discuss? ;-)

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

@p5pRT
Copy link
Author

p5pRT commented Apr 8, 2019

From @Grinnz

Updated patch attached. I chose option 1 (use Exporter 5.57) for the sake of avoiding the distraction of explaining backcompat here, it creates a readable error message, and it allows auto-prereqs heuristics to add the proper version requirement.

@p5pRT
Copy link
Author

p5pRT commented Apr 8, 2019

From @Grinnz

0001-modernize-Exporter-usage-in-perlmod-module-template.patch
From 9f5c03fbc29396bc6959755b721b09c61e02aea3 Mon Sep 17 00:00:00 2001
From: Dan Book <grinnz@grinnz.com>
Date: Thu, 7 Mar 2019 19:34:14 -0500
Subject: [PATCH] modernize Exporter usage in perlmod module template

---
 pod/perlmod.pod | 22 +++++++++-------------
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/pod/perlmod.pod b/pod/perlmod.pod
index c87a68d837..23351cbdf2 100644
--- a/pod/perlmod.pod
+++ b/pod/perlmod.pod
@@ -447,21 +447,17 @@ create a file called F<Some/Module.pm> and start with this template:
     use strict;
     use warnings;
 
-    BEGIN {
-        require Exporter;
+    # Get the import method from Exporter to export functions and variables
+    use Exporter 5.57 'import';
 
-        # set the version for version checking
-        our $VERSION     = 1.00;
+    # set the version for version checking
+    our $VERSION     = '1.00';
 
-        # Inherit from Exporter to export functions and variables
-        our @ISA         = qw(Exporter);
+    # Functions and variables which are exported by default
+    our @EXPORT      = qw(func1 func2);
 
-        # Functions and variables which are exported by default
-        our @EXPORT      = qw(func1 func2);
-
-        # Functions and variables which can be optionally exported
-        our @EXPORT_OK   = qw($Var1 %Hashit func3);
-    }
+    # Functions and variables which can be optionally exported
+    our @EXPORT_OK   = qw($Var1 %Hashit func3);
 
     # exported package globals go here
     our $Var1    = '';
@@ -487,7 +483,7 @@ create a file called F<Some/Module.pm> and start with this template:
     sub func1      { ... }
     sub func2      { ... }
 
-    # this one isn't exported, but could be called directly
+    # this one isn't always exported, but could be called directly
     # as Some::Module::func3()
     sub func3      { ... }
 
-- 
2.20.1

@p5pRT
Copy link
Author

p5pRT commented Apr 9, 2019

From @xsawyerx

A +1 from me.

Thank you for doing this. We need more of it.

On 4/9/19 1​:28 AM, Dan Book via RT wrote​:

Updated patch attached. I chose option 1 (use Exporter 5.57) for the sake of avoiding the distraction of explaining backcompat here, it creates a readable error message, and it allows auto-prereqs heuristics to add the proper version requirement.

---
via perlbug​: queue​: perl5 status​: open
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133909

@p5pRT
Copy link
Author

p5pRT commented Apr 9, 2019

From @xsawyerx

On 4/9/19 1​:13 AM, demerphq wrote​:

On Mon, 8 Apr 2019 at 07​:47, Sawyer X <xsawyerx@​gmail.com> wrote​:

[1] Without going into the argument of "this is ancient" or what the
definition of "billions" is.
There are two definitions of "billion". Which one did you not want to
discuss? ;-)

Neither. (Or is it "neither"?)

@p5pRT
Copy link
Author

p5pRT commented Apr 15, 2019

From @tonycoz

On Mon, 08 Apr 2019 15​:28​:17 -0700, grinnz@​gmail.com wrote​:

Updated patch attached. I chose option 1 (use Exporter 5.57) for the
sake of avoiding the distraction of explaining backcompat here, it
creates a readable error message, and it allows auto-prereqs
heuristics to add the proper version requirement.

Thanks, applied as b634e87.

I had to wrap the​:

# Get the import method from Exporter to export functions and variables

line as podcheck complained.

Tony

@p5pRT
Copy link
Author

p5pRT commented Apr 15, 2019

@tonycoz - Status changed from 'open' to 'pending release'

@p5pRT
Copy link
Author

p5pRT commented May 22, 2019

From @khwilliamson

Thank you for filing this report. You have helped make Perl better.

With the release today of Perl 5.30.0, this and 160 other issues have been
resolved.

Perl 5.30.0 may be downloaded via​:
https://metacpan.org/release/XSAWYERX/perl-5.30.0

If you find that the problem persists, feel free to reopen this ticket.

@p5pRT
Copy link
Author

p5pRT commented May 22, 2019

@khwilliamson - Status changed from 'pending release' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant