'-MModule=100' not identical to 'use Module 100;' when module doesnt use Exporter

p5pRT commented 18 years ago

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

Searchable as RT37292$

p5pRT commented 18 years ago

From @demerphq

Created by @demerphq

It seems there is a discrepancy between how module version checks work from the command line when the module does not use exporter.

Assuming the following modules are available:

package TestVersion::NoExporter; $VERSION=1.0; 1;

package TestVersion::Exporter; use base qw(Exporter); $VERSION=1.0; 1;

Then

perl -MTestVersion::NoExporter=100 -e1

will NOT throw an error. BUT

perl -MTestVersion::Exporter=100 -e1

DOES throw an error.

However\,

perl -e"use TestVersion::NoExporter 100;"

and

perl -e"use TestVersion::Exporter 100;"

are both ok as they both throw an error.

This behaviour is counterintuitive and potentially dangerous and explains why -MModule=VERSION doesnt work consistantly.

EG:

D:\Dev\test>perl -Id:\dev\test -MTestVersion::Exporter=100 -e1 TestVersion::Exporter version 100 required--this is only version 1 at E:/Perl/811/lib/Exporter/Heavy.pm line 121. BEGIN failed--compilation aborted.

D:\Dev\test>perl -Id:\dev\test -MTestVersion::NoExporter=100 -e1

D:\Dev\test>perl -Id:\dev\test -e "use TestVersion::NoExporter 100" TestVersion::NoExporter version 100 required--this is only version 1 at -e line 1. BEGIN failed--compilation aborted at -e line 1.

D:\Dev\test>perl -Id:\dev\test -e "use TestVersion::NoExporter qw(100)"

D:\Dev\test>perl -Id:\dev\test -e "use TestVersion::Exporter 100" TestVersion::Exporter version 100 required--this is only version 1 at -e line 1. BEGIN failed--compilation aborted at -e line 1.

D:\Dev\test>perl -Id:\dev\test -e "use TestVersion::Exporter qw(100)" TestVersion::Exporter version 100 required--this is only version 1 at E:/Perl/811/lib/Exporter/Heavy.pm line 121. BEGIN failed--compilation aborted at -e line 1.

D:\Dev\test>

The error messages suggest to me that Exporter is more clever about handling version checks than the core is. I guess this makes it a bug in UNIVERSAL::VERSION().

cheers\, yves

Perl Info

``` Flags: category=core severity=medium Site configuration information for perl v5.8.6: Configured by ActiveState at Mon Dec 13 09:51:32 2004. Summary of my perl5 (revision 5 version 8 subversion 6) configuration: Platform: osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cl', ccflags ='-nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DNO_HASH_SEED -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX', optimize='-MD -Zi -DNDEBUG -O1', cppflags='-DWIN32' ccversion='', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf -libpath:"E:\Perl\811\lib\CORE" -machine:x86' libpth=\lib libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib gnulibc_version='undef' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref,icf -libpath:"E:\Perl\811\lib\CORE" -machine:x86' Locally applied patches: ACTIVEPERL_LOCAL_PATCHES_ENTRY 21540 Fix backward-compatibility issues in if.pm 23565 Wrong MANIFEST.SKIP @INC for perl v5.8.6: D:\ASPN\PDK\lib\ E:/Perl/811/lib E:/Perl/811/site/lib . Environment for perl v5.8.6: HOME=D:\home LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=E:\sybase\OLEDB;E:\sybase\ODBC;E:\sybase\ASEP_Win32;E:\sybase\OCS-12_5\dll;E:\sybase\OCS-12_5\lib3p;E:\sybase\OCS-12_5\bin;C:\dotNet\Common7\IDE;C:\dotNet\VC7\BIN;C:\dotNet\Common7\Tools;C:\dotNet\Common7\Tools\bin\prerelease;C:\dotNet\Common7\Tools\bin;C:\dotNet\FrameworkSDK\bin;C:\WINDOWS\Microsoft.NET\Framework\v1.0.3705;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;C:\BIN;E:\uedit32;E:\Perl\811\bin;E:\Perl\638\bin;D:\ASPN\PDK\bin;D:\ASPN\Komodo;E:\cygwin\bin PERL5LIB=D:\ASPN\PDK\lib\ PERLDB_OPTS=RemotePort=127.0.0.1:2000 PERL_BADLANG (unset) SHELL (unset) ```

p5pRT commented 18 years ago

From @rgs

yves orton (via RT) wrote:

This behaviour is counterintuitive and potentially dangerous and explains why -MModule=VERSION doesnt work consistantly.

But it's documented in perlrun. Not a bug.

$ perl -MO=Deparse -Mlib=1 -e1 use lib (split(/\,/\, '1'\, 0)); '???'; -e syntax OK

Looks like you want :

$ perl -MO=Deparse -Mlib\ 1 -e1 lib version 1 required--this is only version 0.5565. BEGIN failed--compilation aborted. use lib 1;

p5pRT commented 18 years ago

@rgs - Status changed from 'new' to 'rejected'

p5pRT commented 18 years ago

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

p5pRT commented 18 years ago

From @demerphq

On 9/27/05\, Rafael Garcia-Suarez \rgarciasuarez@mandriva\.com wrote:

yves orton (via RT) wrote:

This behaviour is counterintuitive and potentially dangerous and explains why -MModule=VERSION doesnt work consistantly.

But it's documented in perlrun. Not a bug.
$ perl \-MO=Deparse \-Mlib=1 \-e1
use lib $split\(/\,/\, '1'\, 0$\);
'???';
\-e syntax OK
Looks like you want :
$ perl \-MO=Deparse \-Mlib\\ 1 \-e1
lib version 1 required\-\-this is only version 0\.5565\.
BEGIN failed\-\-compilation aborted\.
use lib 1;

I dont see anywhere in perlrun that explains why this construct should depend on whether the modules uses Exporter.

I can't see how this inconsistant behaviour can be considered to not be a bug.

Its either a bug in Exporter\, or its a bug in UNIVERSAL::VERSION as the two behaviours are inconsistant.

I really dont think this issue should just be ignored. One of the two is doing things wrong.

Yves

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

p5pRT commented 18 years ago

From @demerphq

On 9/27/05\, Rafael Garcia-Suarez \rgarciasuarez@gmail\.com wrote:

On 9/27/05\, demerphq \demerphq@gmail\.com wrote:

I dont see anywhere in perlrun that explains why this construct should depend on whether the modules uses Exporter.

Run your examples through B::Deparse\, and you'll see it's very consistent. Exporter checks what's passed to import()\, hence what you think is an inconsistency. And there is absolutely no version string or version check in your examples; just like C\<use Foo "1"> doesn't do a version check but an import() call.

Therefore Explorer does it wrong.

And frankly justifying this by B::Deparse doesn't to me provide a very convincing argument. We know that Deparse will see these constructs as different as they produce different results. The point is that they shouldn't produce different results.

So it seems to me that you are saying the bug is in Exporter.

Fine\, the bug is in Exporter. But the fact that there is a bug is to me indisputable.

The point is that

perl -MData::Dumper=100 -e1

does something useful because it uses Exporter.pm

But

perl -MCGI::Application=100 -e1

does nothing useful because it doesnt use Exporter.pm.

IMO the behaviour of Exporter is actually useful\, and the behaviour without it is not\, so if i had the option id change the latter.

Regardless\, i dont see how the inconsistancy can be considered to be anything but a bug.

At the very least the difference should be documented in perlrun and in the 'use' documentation.

D:\Dev\test>perl -MO=Deparse -MData::Dumper=100 -e1 Data::Dumper version 100 required--this is only version 2.121_02 at E:/Perl/811/lib/Exporter/Heavy.pm line 121. BEGIN failed--compilation aborted. use Data::Dumper (split(/\,/\, '100'\, 0));

D:\Dev\test>perl -MO=Deparse -MCGI::Application=100 -e1 use CGI::Application (split(/\,/\, '100'\, 0)); '???'; -e syntax OK

Yves

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

p5pRT commented 18 years ago

From @rgarcia

On 9/27/05\, demerphq \demerphq@gmail\.com wrote:

I dont see anywhere in perlrun that explains why this construct should depend on whether the modules uses Exporter.

Run your examples through B::Deparse\, and you'll see it's very consistent. Exporter checks what's passed to import()\, hence what you think is an inconsistency. And there is absolutely no version string or version check in your examples; just like C\<use Foo "1"> doesn't do a version check but an import() call.

p5pRT commented 18 years ago

From @rgs

demerphq wrote:

On 9/27/05\, Rafael Garcia-Suarez \rgarciasuarez@gmail\.com wrote:

On 9/27/05\, demerphq \demerphq@gmail\.com wrote:

I dont see anywhere in perlrun that explains why this construct should depend on whether the modules uses Exporter.

Run your examples through B::Deparse\, and you'll see it's very consistent. Exporter checks what's passed to import()\, hence what you think is an inconsistency. And there is absolutely no version string or version check in your examples; just like C\<use Foo "1"> doesn't do a version check but an import() call.

Therefore Explorer does it wrong.

In which way ?

You know that Exporter has nothing to do with version checks\, it's handled separately (that's why you can mix import arguments *and* version arguments\, as in C\<use Module 1.0 qw(symbol1 symbol2)>.) It happens that Exporter tries to be helpful by calling the VERSION() method on the imported package if it sees a symbol that begins with a number. Trying to be helpful is not really a bug IMHO\, even if it might be confusing.

In other words\, let Foo be a module that uses Exporter : then\, use Foo 1; will use the built-in VERSION check\, and use Foo "1"; will defer it to Exporter. Without Exporter "1" will just be passed to import() (if import() exists) and what import() will do is up to the author of Foo.

Moreover -MFoo=1 generates code equivalent to C\<use Foo "1">\, and not to C\<use Foo 1>\, which can only be replicated on the command line by the hack -MFoo\ 1.

And frankly justifying this by B::Deparse doesn't to me provide a very convincing argument. We know that Deparse will see these constructs as different as they produce different results. The point is that they shouldn't produce different results.

In this case B::Deparse produces accurate results. But you can check perl.c's handling of the -M and -m switches if you want more evidence.

So it seems to me that you are saying the bug is in Exporter.

No\, I'm saying that there is no bug.

p5pRT commented 18 years ago

From @demerphq

On 9/27/05\, Rafael Garcia-Suarez \rgarciasuarez@mandriva\.com wrote:

demerphq wrote:

On 9/27/05\, Rafael Garcia-Suarez \rgarciasuarez@gmail\.com wrote:

On 9/27/05\, demerphq \demerphq@gmail\.com wrote:

I dont see anywhere in perlrun that explains why this construct should depend on whether the modules uses Exporter.

Run your examples through B::Deparse\, and you'll see it's very consistent. Exporter checks what's passed to import()\, hence what you think is an inconsistency. And there is absolutely no version string or version check in your examples; just like C\<use Foo "1"> doesn't do a version check but an import() call.

Therefore Explorer does it wrong.

In which way ?

You know that Exporter has nothing to do with version checks\, it's handled separately (that's why you can mix import arguments *and* version arguments\, as in C\<use Module 1.0 qw(symbol1 symbol2)>.) It happens that Exporter tries to be helpful by calling the VERSION() method on the imported package if it sees a symbol that begins with a number. Trying to be helpful is not really a bug IMHO\, even if it might be confusing.

Personally I consider the inconsistancy a bug. And i think most "normal" users would agree. When i raised it amongst a group of users there was general acknowledgement that the inconsistancy is undesirable\, and I was thanked by at least one for pointing out why -MModule=100 "sometimes doesn't work".

In other words\, let Foo be a module that uses Exporter : then\, use Foo 1; will use the built-in VERSION check\, and use Foo "1"; will defer it to Exporter. Without Exporter "1" will just be passed to import() (if import() exists) and what import() will do is up to the author of Foo.

Yes I understand the mechanism at the heart of this. I'm saying that its behaviour is undesirable.

Moreover -MFoo=1 generates code equivalent to C\<use Foo "1">\, and not to C\<use Foo 1>\, which can only be replicated on the command line by the hack -MFoo\ 1.

Which is undesirable no? Why should people be forced to use hack for this?

And if we are expecting people to use a hack then we should document the hack.

And frankly justifying this by B::Deparse doesn't to me provide a very convincing argument. We know that Deparse will see these constructs as different as they produce different results. The point is that they shouldn't produce different results.

In this case B::Deparse produces accurate results. But you can check perl.c's handling of the -M and -m switches if you want more evidence.

You are misunderstanding my point. My point isnt that the code is not doing what it is supposed to do\, my point is that what its supposed to do appears to be buggy to the eyes of any non guru level perl programmer. Which IMO doesnt seem to me to be most desirable situation.

So it seems to me that you are saying the bug is in Exporter.

No\, I'm saying that there is no bug.

Well\, with all due respect I think you are taking a too "internals" point of view on this.

If you define "bug" as "the code doing what it shouldnt do" then fine\, no bug. If you define "bug" as being "undesirable behaviour" then I'd say that this is a bug.

But if the best that can happen is a patch to perlrun then here goes (attached as well just in case gmail fucks^Wmunges it)

Inline Patch

```diff --- perlrun.pod.orig 2005-09-27 18:41:32.844375000 +0200 +++ perlrun.pod 2005-09-27 18:46:43.703750000 +0200 @@ -589,7 +589,12 @@ C<'-Mmodule qw(foo bar)'>. This avoids the need to use quotes when importing symbols. The actual code generated by B<-Mmodule=foo,bar> is C. Note that the C<=> form -removes the distinction between B<-m> and B<-M>. +removes the distinction between B<-m> and B<-M>, and that it also +implies that you cannot use the C<=> form to reliably do a version check +of the module. Instead you should use the hack C<-MModule\ VERSION=foo,bar> +or C<-M"Module VERSION=foo,bar"> or C<'-MModule VERSION=foo,bar'> (depending +on your shell) instead. + ```

cheers, Yves

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

p5pRT commented 18 years ago

From @demerphq

perlrun.pod.patch

```diff --- perlrun.pod.orig 2005-09-27 18:41:32.844375000 +0200 +++ perlrun.pod 2005-09-27 18:46:43.703750000 +0200 @@ -589,7 +589,12 @@ C<'-Mmodule qw(foo bar)'>. This avoids the need to use quotes when importing symbols. The actual code generated by B<-Mmodule=foo,bar> is C. Note that the C<=> form -removes the distinction between B<-m> and B<-M>. +removes the distinction between B<-m> and B<-M>, and that it also +implies that you cannot use the C<=> form to reliably do a version check +of the module. Instead you should use the hack C<-MModule\ VERSION=foo,bar> +or C<-M"Module VERSION=foo,bar"> or C<'-MModule VERSION=foo,bar'> (depending +on your shell) instead. + =item B<-n> ```

p5pRT commented 18 years ago

From @rgarcia

On 9/27/05\, demerphq \demerphq@gmail\.com wrote:

If you define "bug" as "the code doing what it shouldnt do" then fine\, no bug. If you define "bug" as being "undesirable behaviour" then I'd say that this is a bug.

But if the best that can happen is a patch to perlrun then here goes (attached as well just in case gmail fucks^Wmunges it)

perlrun isn't the place to document this\, or not like this; it should rather say that "-MFoo=number" never does a version check. The fact that Exporter fakes version checks is already documented in the Exporter manpage.

--- perlrun.pod.orig 2005-09-27 18:41:32.844375000 +0200 +++ perlrun.pod 2005-09-27 18:46:43.703750000 +0200 @@ -589\,7 +589\,12 @@ C\<'-Mmodule qw(foo bar)'>. This avoids the need to use quotes when importing symbols. The actual code generated by B\<-Mmodule=foo\,bar> is C\<use module split(/\,/\,q{foo\,bar})>. Note that the C\<=> form -removes the distinction between B\<-m> and B\<-M>. +removes the distinction between B\<-m> and B\<-M>\, and that it also +implies that you cannot use the C\<=> form to reliably do a version check +of the module. Instead you should use the hack C\<-MModule\ VERSION=foo\,bar> +or C\<-M"Module VERSION=foo\,bar"> or C\<'-MModule VERSION=foo\,bar'> (depending +on your shell) instead. +

cheers\, Yves

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

p5pRT commented 18 years ago

From @demerphq

On 9/27/05\, Rafael Garcia-Suarez \rgarciasuarez@gmail\.com wrote:

On 9/27/05\, demerphq \demerphq@gmail\.com wrote:

If you define "bug" as "the code doing what it shouldnt do" then fine\, no bug. If you define "bug" as being "undesirable behaviour" then I'd say that this is a bug.

But if the best that can happen is a patch to perlrun then here goes (attached as well just in case gmail fucks^Wmunges it)

perlrun isn't the place to document this\, or not like this; it should rather say that "-MFoo=number" never does a version check. The fact that Exporter fakes version checks is already documented in the Exporter manpage.

I dont think the consumer of a module cares whether Exporter does it or not. In fact I dont think the consumer of a module should even care what the innards of the module does. So this behaviour being documented in Exporter is pretty useless isnt it? I mean having it documented there doesnt tell me anything about how module X will behave in this situation.

Thus i think my wording is quite reasonable. Many modules use Exporter\, and therefore the version check is performed. And people have direct experience of this\, so saying \<-MFoo=number" never does a version check.> is just incorrect. It does a version check if the module uses Exporter. It does not if it doesnt. Thus as a mechanism to determine/prove the version of the module being used it is unreliable.

Anyways\, obviously you are free not to apply the patch\, or change it as you like\, but i stand my perception of this issue. A beginner user (or even a more advanced) will and do find the behaviour to be confusing and inexplicable. Sure a detailed tracing of the implications of the various docs that impact this issue put it in the "not a bug" category\, but the perceived behaviour is totally the opposite.

Regardless\, im going to stop banging my head on the wall trying to resolve this issue.

Thanks for your feedback.

--- perlrun.pod.orig 2005-09-27 18:41:32.844375000 +0200 +++ perlrun.pod 2005-09-27 18:46:43.703750000 +0200 @@ -589\,7 +589\,12 @@ C\<'-Mmodule qw(foo bar)'>. This avoids the need to use quotes when importing symbols. The actual code generated by B\<-Mmodule=foo\,bar> is C\<use module split(/\,/\,q{foo\,bar})>. Note that the C\<=> form -removes the distinction between B\<-m> and B\<-M>. +removes the distinction between B\<-m> and B\<-M>\, and that it also +implies that you cannot use the C\<=> form to reliably do a version check +of the module. Instead you should use the hack C\<-MModule\ VERSION=foo\,bar> +or C\<-M"Module VERSION=foo\,bar"> or C\<'-MModule VERSION=foo\,bar'> (depending +on your shell) instead. +

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

p5pRT commented 18 years ago

From @schwern

If I can step in here for a moment.

The fact that there's a functionality difference between 1 and "1" is weird.
Perl is supposed to handle string-like-numbers and numbers in pretty much the same way. There's few cases where foo("1") and foo(1) act differently and where they do its generally a trap.

So trying to explain that "use Foo 1" and "use Foo '1'" do different things is going to cause a bit of disbelief. It strikes me as an internal optimization leaking out. If I had to guess\, Perl is doing a version check if the argument is an NV or IV and passing it along to import() if its a PV. There's nothing stopping it from looking at a PV to see if its a number. As we expect this from Exporter-based modules\, and we expect Perl to generally treat "1" and 1 the same\, it probably should.

-- Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern ROCKS FALL! EVERYONE DIES! http://www.somethingpositive.net/sp05032002.shtml

p5pRT commented 18 years ago

From Robin.Barker@npl.co.uk

-----Original Message----- From: demerphq [mailto:demerphq@gmail.com] Sent: 27 September 2005 18:15 To: Rafael Garcia-Suarez Cc: Perl Porters 5 Subject: Re: [perl #37292] '-MModule=100' not identical to 'use Module 100;' when module doesnt use Exporter

On 9/27/05\, Rafael Garcia-Suarez \rgarciasuarez@gmail\.com wrote:

On 9/27/05\, demerphq \demerphq@gmail\.com wrote:

If you define "bug" as "the code doing what it shouldnt do" then fine\, no bug. If you define "bug" as being "undesirable behaviour" then I'd say that this is a bug.

But if the best that can happen is a patch to perlrun then here goes (attached as well just in case gmail fucks^Wmunges it)

perlrun isn't the place to document this\, or not like this; it should rather say that "-MFoo=number" never does a version check. The fact that Exporter fakes version checks is already documented in the Exporter manpage.

I dont think the consumer of a module cares whether Exporter does it or not. In fact I dont think the consumer of a module should even care what the innards of the module does. So this behaviour being documented in Exporter is pretty useless isnt it? I mean having it documented there doesnt tell me anything about how module X will behave in this situation.

I think we could introduce some new command-line syntax

C\<\< -mModule=>VERSION >>\, C\<\< -MModule=>VERSION >>

which translate to C\\, C\. The "=>" is chosen to be close to the other syntax to suggest the Module (version) is greater than or equal VERSION.

Robin

This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee\, you must not use\, retain or disclose such information.

NPL Management Ltd cannot guarantee that the e-mail or any attachments are free from viruses.

NPL Management Ltd. Registered in England and Wales. No: 2937881 Registered Office: Serco House\, 16 Bartley Wood Business Park\, Hook\, Hampshire\, United Kingdom RG27 9UY

p5pRT commented 18 years ago

From @rgarcia

On 9/27/05\, demerphq \demerphq@gmail\.com wrote:

I dont think the consumer of a module cares whether Exporter does it or not. In fact I dont think the consumer of a module should even care what the innards of the module does. So this behaviour being documented in Exporter is pretty useless isnt it? I mean having it documented there doesnt tell me anything about how module X will behave in this situation.

The core docs\, being the definitive reference\, must provide accurate information and not hide complexity. That would be the jobs of tutorials or books/articles.

I thus applied this patch :

Change 25623 by rgs@marais on 2005/09/27 17:02:42

Clarify what -MFoo=number does on the command-line

Affected files ...

... //depot/perl/pod/perlrun.pod#137 edit

Differences ...

==== //depot/perl/pod/perlrun.pod#137 (text) ====

@@ -620\,6 +620\,10 @@ C\<use module split(/\,/\,q{foo\,bar})>. Note that the C\<=> form removes the distinction between B\<-m> and B\<-M>.

+A consequence of this is that B\<-MFoo=number> never does a version check +(unless C\<Foo::import()> itself is set up to do a version check\, which +could happen for example if Foo inherits from Exporter.) + =item B\<-n>

causes Perl to assume the following loop around your program\, which

p5pRT commented 18 years ago

From @rgarcia

On 9/27/05\, Michael G Schwern \schwern@pobox\.com wrote:

If I can step in here for a moment.

The fact that there's a functionality difference between 1 and "1" is weird. Perl is supposed to handle string-like-numbers and numbers in pretty much the same way. There's few cases where foo("1") and foo(1) act differently and where they do its generally a trap.

Just don't get me started on modules named "v1.pm" :)

So trying to explain that "use Foo 1" and "use Foo '1'" do different things is going to cause a bit of disbelief. It strikes me as an internal optimization leaking out. If I had to guess\, Perl is doing a version check if the argument is an NV or IV and passing it along to import() if its a PV. There's nothing stopping it from looking at a PV to see if its a number. As we expect this from Exporter-based modules\, and we expect Perl to generally treat "1" and 1 the same\, it probably should.

I think this falls in the category "won't fix". I'm not very inclined to modify the syntax of the use statement\, which is already scary and relied upon in many weird ways.

Version numbers and version strings must be specified as literals and be followed by a space or a semicolon to be recognized as such. C\<use lib 1 \, $path> is a syntax error because no expression begins with a "\,". C\<use lib 1\, $path> adds "1" to @INC. C\<use lib 1 $path> fails to compile because lib.pm hasn't reached version 1 yet. High levels of dark magic in there.

p5pRT commented 18 years ago

From @demerphq

On 9/27/05\, Rafael Garcia-Suarez \rgarciasuarez@gmail\.com wrote:

On 9/27/05\, demerphq \demerphq@gmail\.com wrote: +A consequence of this is that B\<-MFoo=number> never does a version check +(unless C\<Foo::import()> itself is set up to do a version check\, which +could happen for example if Foo inherits from Exporter.) + =item B\<-n>

I dont think this is that great a patch as it doesnt show how you CAN use the command line to get a version check. Which i think is much more useful information that explaining that Exporter does on occasion make -MModule=VERSION work. Doesnt help much when it doesn't. And I dont think that many users will immediately pick up on the space trick.

yves

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

p5pRT commented 18 years ago

From @ysth

On Tue\, Sep 27\, 2005 at 10:21:30AM -0700\, Michael G Schwern wrote:

If I can step in here for a moment.

The fact that there's a functionality difference between 1 and "1" is weird.
Perl is supposed to handle string-like-numbers and numbers in pretty much the same way. There's few cases where foo("1") and foo(1) act differently and where they do its generally a trap.

So trying to explain that "use Foo 1" and "use Foo '1'" do different things is going to cause a bit of disbelief. It strikes me as an internal optimization leaking out. If I had to guess\, Perl is doing a version check if the argument is an NV or IV and passing it along to import() if its a PV. There's nothing stopping it from looking at a PV to see if its a number. As we expect this from Exporter-based modules\, and we expect Perl to generally treat "1" and 1 the same\, it probably should.

But this is an exception to the "generally". The syntax documents it as being a VERSION; it's quite reasonable to me that 1 is a version and "1" is not.

I see this as not much different from the totally different meanings of C\ and C\<require "Foo">.

p5pRT commented 18 years ago

From @rgarcia

On 9/27/05\, demerphq \demerphq@gmail\.com wrote:

I dont think this is that great a patch as it doesnt show how you CAN use the command line to get a version check.

Yes\, that's because I like Robin's suggestion :) (but I'm not going to document something that's not implemented yet)

p5pRT commented 18 years ago

From @demerphq

On 9/27/05\, Rafael Garcia-Suarez \rgarciasuarez@gmail\.com wrote:

On 9/27/05\, demerphq \demerphq@gmail\.com wrote:

I dont think this is that great a patch as it doesnt show how you CAN use the command line to get a version check.

Yes\, that's because I like Robin's suggestion :) (but I'm not going to document something that's not implemented yet)

Ok\, thats fair enough. If Robins suggestion is to become the future then great.

cheers\, yves

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

p5pRT commented 18 years ago

From @ysth

On Tue\, Sep 27\, 2005 at 07:44:44PM +0200\, Rafael Garcia-Suarez wrote:

On 9/27/05\, demerphq \demerphq@gmail\.com wrote:

I dont think this is that great a patch as it doesnt show how you CAN use the command line to get a version check.

Yes\, that's because I like Robin's suggestion :) (but I'm not going to document something that's not implemented yet)

'>' is easy to remember\, but a lousy character to expect in a command-line option. Any other suggestions?

p5pRT commented 18 years ago

From @demerphq

On 9/27/05\, Yitzchak Scott-Thoennes \sthoenna@efn\.org wrote:

On Tue\, Sep 27\, 2005 at 07:44:44PM +0200\, Rafael Garcia-Suarez wrote:

On 9/27/05\, demerphq \demerphq@gmail\.com wrote:

I dont think this is that great a patch as it doesnt show how you CAN use the command line to get a version check.

Yes\, that's because I like Robin's suggestion :) (but I'm not going to document something that's not implemented yet)

'>' is easy to remember\, but a lousy character to expect in a command-line option. Any other suggestions?

:

perl -MCGI::Application:=100 -e1

so that the pascal types out there feel nice and homey :-)

Although maybe += would be better...

yves

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

p5pRT commented 18 years ago

From @rgarcia

On 9/27/05\, Yitzchak Scott-Thoennes \sthoenna@efn\.org wrote:

'>' is easy to remember\, but a lousy character to expect in a command-line option. Any other suggestions?

-MModule~version=importlist ?

p5pRT commented 18 years ago

From @schwern

On Tue\, Sep 27\, 2005 at 10:40:50AM -0700\, Yitzchak Scott-Thoennes wrote:

But this is an exception to the "generally". The syntax documents it as being a VERSION; it's quite reasonable to me that 1 is a version and "1" is not.

I'm curious why you think that's reasonable? What about VERSION suggests "bareword" and not simply "number"?

I see this as not much different from the totally different meanings of C\ and C\<require "Foo">.

Which is a bit of a hack and not a shining example of good interface design. Different meanings for bareword vs string arguments cause confusion and make any sort of dynamic statements difficult. Case in point\, the many pitfalls of trying to require $module. See also filehandles.

-- Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern Life is like a sewer - what you get out of it depends on what you put into it. - Tom Lehrer

p5pRT commented 18 years ago

From @schwern

On Tue\, Sep 27\, 2005 at 07:52:45PM +0200\, Rafael Garcia-Suarez wrote:

On 9/27/05\, Yitzchak Scott-Thoennes \sthoenna@efn\.org wrote:

'>' is easy to remember\, but a lousy character to expect in a command-line option. Any other suggestions?

-MModule~version=importlist ?

Umm\, is it REALLY all that important that folks have a way of requiring a certain version of a module in a one-liner to the point of adding new and cryptic syntax that won't be available until 5.10 anyway?

Wouldn't fixing it to handle string versions be less confusing than fixing a special case with another special case?

-- Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern Reality is that which\, when you stop believing in it\, doesn't go away. -- Phillip K. Dick

p5pRT commented 18 years ago

From @rgarcia

On 9/27/05\, Michael G Schwern \schwern@pobox\.com wrote:

-MModule~version=importlist ?

Umm\, is it REALLY all that important that folks have a way of requiring a certain version of a module in a one-liner to the point of adding new and cryptic syntax that won't be available until 5.10 anyway?

That's a point. Esp. since that Can Already Be Done By Using Documented Syntax. And\, well\, honestly\, I don't see the point of version numbers on one-liners\, honestly.

Wouldn't fixing it to handle string versions be less confusing than fixing a special case with another special case?

what kind of string versions ?

Currently the boundary is clear : if the first argument is a numeric literal or a version string\, and if it's not immediately followed by a comma (sic)\, then perform a version check.

We can add new syntax\, but not change the meaning of already existing syntax. That is : C\<use lib "1"> and C\<use lib $version> will continue to call import(). The only new possibility left is C\<use lib "1" "2";> or more generally C\<use lib $a $b> (without a comma between the two arguments); which is currently a syntax error. I think it deserves to be a syntax error -- it would be another confusing addition.

p5pRT commented 18 years ago

From vadim@vkonovalov.ru

I dont think this is that great a patch as it doesnt show how you CAN use the command line to get a version check.

Yes\, that's because I like Robin's suggestion :) (but I'm not going to document something that's not implemented yet)

'>' is easy to remember\, but a lousy character to expect in a command-line option. Any other suggestions?

yes\, not only it is a lousy char\, but it will immediately start STDOUT redirection on dosish command shell.

p5pRT commented 18 years ago

From @JohnPeacock

Rafael Garcia-Suarez wrote:

On 9/27/05\, Michael G Schwern \schwern@pobox\.com wrote:

Wouldn't fixing it to handle string versions be less confusing than fixing a special case with another special case?

what kind of string versions ?

These two are special in some sense:

"0.50" "1.2.3"

The former because otherwise EU::MM and M::B create an archive without the trailing zero (which is always implied but confuses some people). The latter is special in that it will only work when version.pm is in force (which Damian is recommending in /Perl Best Practices/). However\, both of them have the advantage of starting with a digit\, so we could simply say "bare number" or "string beginning with a digit" followed by a space before any additional terms. That only leaves the problem of:

"v1.2.3"

to deal with (since that is also allowed syntax under version.pm and is _not_ equivalent to the bareword variant\, except for Perl > 5.8.1).

Currently the boundary is clear : if the first argument is a numeric literal or a version string\, and if it's not immediately followed by a comma (sic)\, then perform a version check.

We can add new syntax\, but not change the meaning of already existing syntax. That is : C\<use lib "1"> and C\<use lib $version> will continue to call import().

I agree that the "bare number" vs "string that looks like a number" is a tokenizer optimization more than anything else. There is no reason we couldn't support strings without error.

The only new possibility left is C\<use lib "1" "2";> or more generally C\<use lib $a $b> (without a comma between the two arguments); which is currently a syntax error. I think it deserves to be a syntax error -- it would be another confusing addition.

I'd have to look at the specific code to see how easy it would be to figure out this one as being different from what we would now be allowing. But I agree it should still be a syntax error.

John

-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham\, MD 20706 301-459-3366 x.5010 fax 301-429-5748

p5pRT commented 18 years ago

From @schwern

On Tue\, Sep 27\, 2005 at 08:14:34PM +0200\, Rafael Garcia-Suarez wrote:

Wouldn't fixing it to handle string versions be less confusing than fixing a special case with another special case?

what kind of string versions ?

Any string which converts cleanly to a number.

Currently the boundary is clear : if the first argument is a numeric literal or a version string\, and if it's not immediately followed by a comma (sic)\, then perform a version check.

We can add new syntax\, but not change the meaning of already existing syntax. That is : C\<use lib "1"> and C\<use lib $version> will continue to call import(). The only new possibility left is C\<use lib "1" "2";> or more generally C\<use lib $a $b> (without a comma between the two arguments); which is currently a syntax error. I think it deserves to be a syntax error -- it would be another confusing addition.

I'm going to debate with myself for a moment.

Exporter already handles string versions\, and you'll note the total lack of bits of sky litering the ground. Nobody noticed this issue for years so I don't think it would hurt to make C\<use lib "1"> check the version.

Then again\, having C\<use lib $foo> sometimes add to @INC and sometimes only load lib if its a certain version is just about as confusing\, if not moreso\, than magic bareword syntax.

And since nobody's noticed this for years its not likely to be causing anyone a real problem. Until you try to explain exactly how it works and everyone goes "huh?" But otherwise\, if you don't think about it too much\, it works fine and the fix is as bad as the problem.

So I think I've convinced myself that it should be left as is. Improve the docs to explain what a VERSION is more clearly.

If you really want explicit version checks\, use only.pm. This has the nice advantage of not having to wait for 5.10.

use only lib => '1-';

perl -Monly=lib\,'1-' -e 1

PS Somebody should crank up lib's version to at least 1.0.

-- Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern Ahh email\, my old friend. Do you know that revenge is a dish that is best served cold? And it is very cold on the Internet!

p5pRT commented 18 years ago

From @tamias

On Tue\, Sep 27\, 2005 at 07:29:39PM +0200\, Rafael Garcia-Suarez wrote:

==== //depot/perl/pod/perlrun.pod#137 (text) ====

@@ -620\,6 +620\,10 @@ C\<use module split(/\,/\,q{foo\,bar})>. Note that the C\<=> form removes the distinction between B\<-m> and B\<-M>.

+A consequence of this is that B\<-MFoo=number> never does a version check +(unless C\<Foo::import()> itself is set up to do a version check\, which +could happen for example if Foo inherits from Exporter.) +

Nit: that period should be after the closing parenthesis\, because the parenthetical is not a full sentence.

Ronald

p5pRT commented 18 years ago

From @ysth

On Tue\, Sep 27\, 2005 at 11:01:39AM -0700\, Michael G Schwern wrote:

On Tue\, Sep 27\, 2005 at 10:40:50AM -0700\, Yitzchak Scott-Thoennes wrote:

But this is an exception to the "generally". The syntax documents it as being a VERSION; it's quite reasonable to me that 1 is a version and "1" is not.

I'm curious why you think that's reasonable? What about VERSION suggests "bareword" and not simply "number"?

Just that I don't think of versions as being strings.

I see this as not much different from the totally different meanings of C\ and C\<require "Foo">.

Which is a bit of a hack and not a shining example of good interface design. Different meanings for bareword vs string arguments cause confusion and make any sort of dynamic statements difficult. Case in point\, the many pitfalls of trying to require $module. See also filehandles.

I agree that hindsight would dictate a different design\, both for require and for specifying a VERSION to use.

p5pRT commented 18 years ago

From @ysth

On Tue\, Sep 27\, 2005 at 12:30:37PM -0700\, Michael G Schwern wrote:

Exporter already handles string versions\, and you'll note the total lack of bits of sky litering the ground. Nobody noticed this issue for years so I

I noticed that -Mfoo=version didn't always "work" some time ago\, looked into it and discovered that it only worked due to this Exporter feature. It made perfect sense to me\, and I didn't even consider filing a bug report.

don't think it would hurt to make C\<use lib "1"> check the version.

Yes\, but Exporter knows it's getting symbols to export\, and numbers (whether provided as strings or as numeric constants) aren't such symbols\, so it's free to interpret them as versions. In the general case\, module Foo should be allowed to receive numbers in the "import" list without having perl assume they are versions to check.

p5pRT commented 18 years ago

From @gbarr

On Sep 27\, 2005\, at 12:21 PM\, Michael G Schwern wrote:

If I can step in here for a moment.

The fact that there's a functionality difference between 1 and "1"
is weird. Perl is supposed to handle string-like-numbers and numbers in
pretty much the same way. There's few cases where foo("1") and foo(1) act
differently and where they do its generally a trap.

So trying to explain that "use Foo 1" and "use Foo '1'" do
different things is going to cause a bit of disbelief. It strikes me as an internal optimization leaking out. If I had to guess\, Perl is doing a version check if the argument is an NV or IV and passing it along to import () if its a PV. There's nothing stopping it from looking at a PV to see if
its a number. As we expect this from Exporter-based modules\, and we
expect Perl to generally treat "1" and 1 the same\, it probably should.

Let me try to explain how this came about.

At some point in the past UNIVERSAL::VERSION did not exist and perl
had no built-in way of verifying the version of a module as it was
loaded. The functionality was built into Exporter\, but this did mean
that modules that did not inherit from Exporter could not be checked.

It was because of this that I added the version checking capability.
To distinguish the version from the import list perl looks to see if
there is a \, following the first argument. If there is then it is
passed to import\, if there is not it is used as a version and passed
to ->VERSION for checking.

the issue is when there is only one thing after use Module. IIRC if
it looks like a number it's treated as a version otherwise it is
passed to import.

Now to the command line. Just like -n -p and -e -M is used to build a
script which is parsed. -Mmodule=foo is treated as

use module 'foo';

which does meant that -Mmodule\ 99=foo is treated as

use module 99 'foo';

Which will do the version check.

I am not saying this is the right way\, but this is how it came about.

Graham.

p5pRT commented 18 years ago

From @gbarr

On Sep 27\, 2005\, at 13:14 PM\, Rafael Garcia-Suarez wrote:

On 9/27/05\, Michael G Schwern \schwern@pobox\.com wrote:

-MModule~version=importlist ?

Umm\, is it REALLY all that important that folks have a way of
requiring a certain version of a module in a one-liner to the point of
adding new and cryptic syntax that won't be available until 5.10 anyway?

That's a point. Esp. since that Can Already Be Done By Using Documented Syntax. And\, well\, honestly\, I don't see the point of version numbers on one-liners\, honestly.

$ perl -Mlib\ 999 lib version 999 required--this is only version 0.5565. BEGIN failed--compilation aborted.

is very useful to determine which version is installed.

Graham.

p5pRT commented 18 years ago

From @gbarr

On Sep 27\, 2005\, at 12:52 PM\, Rafael Garcia-Suarez wrote:

On 9/27/05\, Yitzchak Scott-Thoennes \sthoenna@efn\.org wrote:

'>' is easy to remember\, but a lousy character to expect in a
command-line option. Any other suggestions?

-MModule~version=importlist ?

-MModule\ version=importlist already works :-)

Graham.

p5pRT commented 18 years ago

From @tux

On Tue\, 27 Sep 2005 20:30:54 -0500\, Graham Barr \gbarr@pobox\.com wrote:

On Sep 27\, 2005\, at 13:14 PM\, Rafael Garcia-Suarez wrote:

On 9/27/05\, Michael G Schwern \schwern@pobox\.com wrote:

-MModule~version=importlist ?

Umm\, is it REALLY all that important that folks have a way of
requiring a certain version of a module in a one-liner to the point of
adding new and cryptic syntax that won't be available until 5.10 anyway?

That's a point. Esp. since that Can Already Be Done By Using Documented Syntax. And\, well\, honestly\, I don't see the point of version numbers on one-liners\, honestly.

$ perl -Mlib\ 999 lib version 999 required--this is only version 0.5565. BEGIN failed--compilation aborted.

is very useful to determine which version is installed.

But that's much easier done with Abe's 'V' module\, which is not on CPAN\, because one-letter modules are not allowed there.

As a `solution' to this discussion\, I propose to add Abe's V to the core /me ducks

lt09:/home/merijn 101 > perl -MV=lib lib /pro/lib/perl5/5.8.7/i686-linux-64int/lib.pm: 0.5565 lt09:/home/merijn 102 >

-- H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/) using Perl 5.6.2\, 5.8.0\, 5.8.5\, & 5.9.2 on HP-UX 10.20\, 11.00 & 11.11\, AIX 4.3 & 5.2\, SuSE 9.2 & 9.3\, and Cygwin. http://www.cmve.net/~merijn Smoking perl: http://www.test-smoke.org\, perl QA: http://qa.perl.org reports to: smokers-reports@perl.org\, perl-qa@perl.org

p5pRT commented 18 years ago

From tassilo.von.parseval@rwth-aachen.de

On Tue\, Sep 27\, 2005 at 04:45:44PM -0700 Yitzchak Scott-Thoennes wrote:

On Tue\, Sep 27\, 2005 at 11:01:39AM -0700\, Michael G Schwern wrote:

On Tue\, Sep 27\, 2005 at 10:40:50AM -0700\, Yitzchak Scott-Thoennes wrote:

But this is an exception to the "generally". The syntax documents it as being a VERSION; it's quite reasonable to me that 1 is a version and "1" is not.

I'm curious why you think that's reasonable? What about VERSION suggests "bareword" and not simply "number"?

Just that I don't think of versions as being strings.

But then I don't think of numbers given as strings as being exportable symbols. A number can never be the name of a function nor of an exportable variable (digit variables always live in main:: and therefore can't really be subject to any exporting).

Subsequently it could easily be made into a version check regardless of whether Exporter is used with the module or not.

Furthermore\, it has been the typical advice (given for years for instance on clpm) that checking the version on the command-line happens by using '-MModule=$VERSION'. There has never been any mentioning of Exporter. I'd say that even many experienced Perl users are not aware of that subtlety.

I also noticed some time ago that -MModule=$VERSION never throws an error on some modules. Until Yves's report I was clueless as to why this is so. Now I understand why Exporter matters with this issue but I find it extremely unconvincing to use this explanation to flag it as non-bug.

IMHO

use Module 1; # and use Module "1";

should be made functionally equivalent instead of pounding on technical reasoning why a number as string is not the same thing as a bareworded number in a use- or require-clause.

I see this as not much different from the totally different meanings of C\ and C\<require "Foo">.

Which is a bit of a hack and not a shining example of good interface design. Different meanings for bareword vs string arguments cause confusion and make any sort of dynamic statements difficult. Case in point\, the many pitfalls of trying to require $module. See also filehandles.

I agree that hindsight would dictate a different design\, both for require and for specifying a VERSION to use.

I think it's preferrable to be consistent with actual human expectation over being consistent with a questionable concept in a related affair (\ versus \<require "Foo">).

Tassilo -- use bigint; $n=71423350343770280161397026330337371139054411854220053437565440; $m=-8\,;;$_=$n&(0xff)\<\<$m\,\,$_>>=$m\,\,print+chr\,\,while(($m+=8)\<=200);

p5pRT commented 18 years ago

From @schwern

On Wed\, Sep 28\, 2005 at 09:23:33AM +0200\, Tassilo von Parseval wrote:

But then I don't think of numbers given as strings as being exportable symbols. A number can never be the name of a function nor of an exportable variable (digit variables always live in main:: and therefore can't really be subject to any exporting).

As you may have noticed\, a lot of modules on CPAN do a lot more with import() than just exporting symbols. There's one in the core\, "use lib".

-- Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern You are wicked and wrong to have broken inside and peeked at the implementation and then relied upon it. -- tchrist in \31832\.969261130@chthon

p5pRT commented 18 years ago

From @demerphq

On 9/28/05\, Michael G Schwern \schwern@pobox\.com wrote:

On Wed\, Sep 28\, 2005 at 09:23:33AM +0200\, Tassilo von Parseval wrote:

But then I don't think of numbers given as strings as being exportable symbols. A number can never be the name of a function nor of an exportable variable (digit variables always live in main:: and therefore can't really be subject to any exporting).

As you may have noticed\, a lot of modules on CPAN do a lot more with import() than just exporting symbols. There's one in the core\, "use lib".

Im trying to think when you would say use lib "1234"; and why it wouldn't be better expressed as "./1234" or "D:/Some/Dir/1234" or whatever.

Im also of the opinion that any module expecting a number as the first argument is going to have fallen prey to problems with people writing

use Blah 1234;

instead of

use Blah "1234";

Anyway\, IMO this issue raises another point. If a module has no import defined then arguments provided via use are silently ignored. If this were not so then people would at least know what is going on when the version number is silently ignored.

So if we aren't going to fix the behaviour of -MModule=$VERSION we could at least make

use CGI::Application "123";

warn with "Arugments to use CGI::Application::import() ignored at ..."

yves

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

p5pRT commented 18 years ago

From @rgarcia

On 9/28/05\, Tassilo von Parseval \tassilo\.von\.parseval@rwth\-aachen\.de wrote:

IMHO
use Module 1;
\# and
use Module "1";
should be made functionally equivalent instead of pounding on technical reasoning why a number as string is not the same thing as a bareworded number in a use- or require-clause.

Currently this is purely a lexing issue. C\<use Module $x> will call Module->import($x) no matter what $x contains -- IV or PV -- and I think that it's a right thing to do. Version checks only happens when the text of the Perl source code contains something that looks like a version after the "use Module".

Moreover it you want to do complex things with version checks\, you can always use only.pm\, or call VERSION() directly\, etc.

What you're proposing is actually to add complexity and special cases\, that is\, to do version checking when the argument to "use" looks like a version string from the point of view of perl's execution engine\, and not from the point of view of perl's tokenizer. I don't like this\, because this will create more confusion in an already confused matter.

And I'm pretty sure there's code out there that relies on current behaviour. (I don't remember the details but I might have written such code myself\, and my name's not Abigail :)

p5pRT commented 18 years ago

From @rgarcia

On 9/28/05\, demerphq \demerphq@gmail\.com wrote:

Anyway\, IMO this issue raises another point. If a module has no import defined then arguments provided via use are silently ignored. If this were not so then people would at least know what is going on when the version number is silently ignored.

So\, write UNIVERSAL::import to do this and put it on CPAN ?

I'm not really comfortable with the idea of providing a default import method to all modules\, whether they like it or not -- even if it just warns.

So if we aren't going to fix the behaviour of -MModule=$VERSION we

It's not to be fixed\, it's not a bug.

p5pRT commented 18 years ago

From @demerphq

On 9/28/05\, Rafael Garcia-Suarez \rgarciasuarez@gmail\.com wrote:

On 9/28/05\, demerphq \demerphq@gmail\.com wrote:

Anyway\, IMO this issue raises another point. If a module has no import defined then arguments provided via use are silently ignored. If this were not so then people would at least know what is going on when the version number is silently ignored.

So\, write UNIVERSAL::import to do this and put it on CPAN ?

Whats the point? Its going to help about 3 people being there. And they are probably smart enough to have already hand hacked one of their own.

I'm not really comfortable with the idea of providing a default import method to all modules\, whether they like it or not -- even if it just warns.

So if we aren't going to fix the behaviour of -MModule=$VERSION we

It's not to be fixed\, it's not a bug.

Whatever\, that seems about as clear as mud.

Could you please just document the hack in perlrun? And IMO you should specifically deprecate the useage of -MModule=$VERSION as the meme is already out there\, is in wide use and should be killed as it is an unrelaible mechanism to determine the version from the command line.

Yves

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

p5pRT commented 18 years ago

From @tamias

On Wed\, Sep 28\, 2005 at 10:31:26AM +0200\, demerphq wrote:

Could you please just document the hack in perlrun? And IMO you should specifically deprecate the useage of -MModule=$VERSION as the meme is already out there\, is in wide use and should be killed as it is an unrelaible mechanism to determine the version from the command line.

Personally\, I always thought `perl -MModule=999999 -e 1` was a silly way of getting the version of a module anyway. Instead of actually asking for what you want\, you're forcing an error so you can dig what you want out of the error message.

I use `perl -MModule -le 'print $Module::VERSION'`. The redundancy is a minor annoyance but it does exactly what I want: prints the version of a module.

Ronald

p5pRT commented 18 years ago

From @schwern

On Wed\, Sep 28\, 2005 at 10:31:26AM +0200\, demerphq wrote:

So\, write UNIVERSAL::import to do this and put it on CPAN ?

Whats the point? Its going to help about 3 people being there. And they are probably smart enough to have already hand hacked one of their own.

It will be available now\, without having to wait for 5.10\, and it will not be necessary to make your code incompatible with earlier versions of Perl to use it.

-- Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern You know what the chain of command is? It's the chain I go get and beat you with 'til you understand who's in ruttin' command here. -- Jayne Cobb\, "Firefly"

p5pRT commented 18 years ago

From prev a.r.ferreira@gmail.com

In the end\, that was a discussion about how Perl 5 was made too smart/concise supporting different interpretations to the similar constructions.

use Module 1; use Module "1";

which correspond respectively to

use Module 1 (); use Module ("1");

It's just a matter of considering the three different arguments C\ may accept: the (required) module\, the (optional) version\, and the (optional) list of imports.

Well\, don't forget the handicapped Windows users (with a shameless horrible command line interpreters) can't do

> perl -MModule\ 1 -e1

as the tokenizer is too stupid. Rafael's short suggestion

perl -MModule~1 -e1

would allow that for the OS-impaired people.

Hey. If it wasn't a light theme\, this thread would look like a nightmare for p5p summarizers. 43 messages is longer than most threads on python-list and ruby-talk and these are for general discussion.

p5pRT commented 18 years ago

From @rgarcia

On 9/28/05\, Adriano Ferreira \a\.r\.ferreira@gmail\.com wrote:

In the end\, that was a discussion about how Perl 5 was made too smart/concise supporting different interpretations to the similar constructions.

use Module 1; use Module "1";

which correspond respectively to

use Module 1 ();

No!! The use syntax is not as simple as that :) An explicit empty list skips calling import() :

[rafael@dat rafael]$ cat Foo.pm package Foo; sub import { print "import(@_)\n" } $VERSION = 2; [rafael@dat rafael]$ perl -e 'use Foo 1 ()' [rafael@dat rafael]$ perl -e 'use Foo 1' import(Foo)

use Module ("1");

It's just a matter of considering the three different arguments C\ may accept: the (required) module\, the (optional) version\, and the (optional) list of imports.

And an (explicit) empty list is not the same as no list at all. One more thing handled at parser level\, not at interpretation level.

Hey. If it wasn't a light theme\, this thread would look like a nightmare for p5p summarizers. 43 messages is longer than most threads on python-list and ruby-talk and these are for general discussion.

Yes. Sorry :) I can feel your pain.

p5pRT commented 18 years ago

From @schwern

On Wed\, Sep 28\, 2005 at 03:08:11PM -0300\, Adriano Ferreira wrote:

Hey. If it wasn't a light theme\, this thread would look like a nightmare for p5p summarizers. 43 messages is longer than most threads on python-list and ruby-talk and these are for general discussion.

It just shows the extra care and attention we devote to even the smallest of issues.

-- Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern Insulting our readers is part of our business model. http://somethingpositive.net/sp07122005.shtml

p5pRT commented 18 years ago

From prev a.r.ferreira@gmail.com

On 9/28/05\, Rafael Garcia-Suarez \rgarciasuarez@gmail\.com wrote:

No!! The use syntax is not as simple as that :) An explicit empty list skips calling import() :

Oops! Well\, in the end\, Perl 5 is even smarter/concise that my poor memory allow me to be. So there is no syntactic equivalent with the three arguments for

use Foo 1;

because

use Foo 1 undef; => use Foo 1 (undef);

It's just a matter of considering the three different arguments C\ may accept: the (required) module\, the (optional) version\, and the (optional) list of imports.

And an (explicit) empty list is not the same as no list at all. One more thing handled at parser level\, not at interpretation level.

This is just like a function with three arguments\, where the third one - the (optional) list of imports - brings different semantics whether it was provided or not and whether it is an empty list or not. (To be true\, the behavior with the provided third argument and a non-empty list are quite close\, but not with an empty list.) A rather peculiar behavior that\, as it is (well) documented\, it is just fine by me.

The C\<perldoc -f use> has the final saying:

use Foo 1; => BEGIN { require Foo 1; import Foo (); } use Foo "1"; => BEGIN { require Foo; import Foo ("1"); } use Foo 1 (); => BEGIN { require Foo 1; } use Foo 1 qw(a); => BEGIN { require Foo 1; import Foo (qw(a)); }

Yes. Sorry :) I can feel your pain.

As I said the topic was light. It was fun even though some get quite exalted.

p5pRT commented 18 years ago

From @schwern

On Wed\, Sep 28\, 2005 at 03:55:00PM -0300\, Adriano Ferreira wrote:

On 9/28/05\, Michael G Schwern \schwern@pobox\.com wrote:

It just shows the extra care and attention we devote to even the smallest of issues.

I think that's what makes Perl what it is.

I thought it was the coffee\, hard liquor and sarcasm.

-- Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern Stabbing you in the face for your own good.

p5pRT commented 18 years ago

From itub@cpan.org

Adriano Ferreira wrote:

Well\, don't forget the handicapped Windows users (with a shameless horrible command line interpreters) can't do

perl -MModule\ 1 -e1

as the tokenizer is too stupid. Rafael's short suggestion

perl -MModule~1 -e1

would allow that for the OS-impaired people.

Thhis works fine in Windows:

perl "-MModule 1"

-- Ivan

Perl / perl5