Mailing List Archive

removing the old-style package separator
Porters,

Since at least 2009 <http://markmail.org/message/gaux5xx5jlop3vmk>, we have been talking, once in a while, about deprecating the use of \N{APOSTROPHE} as a package separator, Ada style.

The following two expressions are equivalent:
$x::y::z

$x'y'z

This mostly goes unnoticed, but the confusion sometimes seeps in at:
print "This is $user's problem to deal with."
…which attempts to interpolate $user::s

This bites experts and new users alike, and while the apostrophe *might* be aesthetically pleasing as a package separator, that battle has basically been lost.

I think the next course of action is to see what on CPAN would really break if the old package separator was removed. I predict "very nearly nothing." Then, to add a deprecation warning for when it is used, with a drop dead date. That is, assuming that we don't realize there's some reason we really ought not to do this.

This is a low-value win, but I think it's a win. Shall we carry on to RFC this?

--
rjbs
Re: removing the old-style package separator [ In reply to ]
On Sat, Aug 14, 2021 at 11:09 PM Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:

> Porters,
>
> Since at least 2009 <http://markmail.org/message/gaux5xx5jlop3vmk>, we
> have been talking, once in a while, about deprecating the use of
> \N{APOSTROPHE} as a package separator, Ada style.
>
> The following two expressions are equivalent:
>
> $x::y::z
>
> $x'y'z
>
>
> This mostly goes unnoticed, but the confusion sometimes seeps in at:
>
> print "This is $user's problem to deal with."
>
> …which attempts to interpolate $user::s
>
> This bites experts and new users alike, and while the apostrophe *might*
> be aesthetically pleasing as a package separator, that battle has basically
> been lost.
>
> I think the next course of action is to see what on CPAN would really
> break if the old package separator was removed. I predict "very nearly
> nothing." Then, to add a deprecation warning for when it is used, with a
> drop dead date. That is, assuming that we don't realize there's some
> reason we really ought not to do this.
>
> This is a low-value win, but I think it's a win. Shall we carry on to RFC
> this?
>

+1 The problems it causes in interpolation far exceed any possible utility,
even if I thought it looked nice (I don't).

-Dan
Re: removing the old-style package separator [ In reply to ]
On 8/14/21 11:08 PM, Ricardo Signes wrote:
> Porters,
>
> Since at least 2009 <http://markmail.org/message/gaux5xx5jlop3vmk>, we
> have been talking, once in a while, about deprecating the use of
> \N{APOSTROPHE} as a package separator, Ada style.
>
> The following two expressions are equivalent:
> $x::y::z
>
> $x'y'z

while i totally agree with this, there are some modules with the name
d'oh in them!

|||use| |D <https://metacpan.org/pod/D>||'oh '||i_hate_this_program';|
|||D||'oh::stderr('||/tmp/stderr'); ||# redirect all stderr to /tmp/stderr|


D'oh::Year <https://metacpan.org/pod/D'oh::Year> - Catch stupid
mistakes when mucking with years, like Y2K bugs


and both seem to do something real and are not in acme::

uri
Re: removing the old-style package separator [ In reply to ]
On Sun, Aug 15, 2021 at 12:07 AM Uri Guttman <uri@stemsystems.com> wrote:

> On 8/14/21 11:08 PM, Ricardo Signes wrote:
>
> Porters,
>
> Since at least 2009 <http://markmail.org/message/gaux5xx5jlop3vmk>, we
> have been talking, once in a while, about deprecating the use of
> \N{APOSTROPHE} as a package separator, Ada style.
>
> The following two expressions are equivalent:
>
> $x::y::z
>
> $x'y'z
>
>
> while i totally agree with this, there are some modules with the name d'oh
> in them!
>
> use D <https://metacpan.org/pod/D>'oh 'i_hate_this_program';
> D'oh::stderr('/tmp/stderr'); # redirect all stderr to /tmp/stderr
>
>
> D'oh::Year <https://metacpan.org/pod/D'oh::Year> - Catch stupid mistakes
> when mucking with years, like Y2K bugs
>
>
> and both seem to do something real and are not in acme::
>

Test::More::isn't is another example of this; but in both cases a
slightly less cute version is perfectly usable without this feature, so I
don't find it a compelling reason against the downsides.

-Dan
Re: removing the old-style package separator [ In reply to ]
On 8/15/21 12:12 AM, Dan Book wrote:
>
> while i totally agree with this, there are some modules with the
> name d'oh in them!
>
> |||use| |D <https://metacpan.org/pod/D>||'oh '||i_hate_this_program';|
> |||D||'oh::stderr('||/tmp/stderr'); ||# redirect all stderr to
> /tmp/stderr|
>
>
> D'oh::Year <https://metacpan.org/pod/D'oh::Year> - Catch
> stupid mistakes when mucking with years, like Y2K bugs
>
>
> and both seem to do something real and are not in acme::
>
>
> Test::More::isn't is another example of this; but in both cases a
> slightly less cute version is perfectly usable without this feature,
> so I don't find it a compelling reason against the downsides.
>
> -Dan

agreed. i don't see a downside but for losing the cuteness. and isn't
could be renamed to isnot. and the two d'oh modules are more jokes than
real. they belong in acme. but they should have their name changed to be
compliant with this deprecation.

it should be easy enough to scan the cpan namespace for apostrophes.
scanning the cpan sources would be tricky IMO as single quotes are
everywhere. if we find all the names and their dependents, those authors
could be notified about the impending apostrophic doom!

uri
Re: removing the old-style package separator [ In reply to ]
On Sat, 14 Aug 2021 23:08:40 -0400
"Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:

> Porters,
>
> Since at least 2009 <http://markmail.org/message/gaux5xx5jlop3vmk>, we have been talking, once in a while, about deprecating the use of \N{APOSTROPHE} as a package separator, Ada style.
>
> The following two expressions are equivalent:
> $x::y::z
>
> $x'y'z
>
> This mostly goes unnoticed, but the confusion sometimes seeps in at:
> print "This is $user's problem to deal with."
> ?which attempts to interpolate $user::s
>
> This bites experts and new users alike, and while the apostrophe *might* be aesthetically pleasing as a package separator, that battle has basically been lost.
>
> I think the next course of action is to see what on CPAN would really break if the old package separator was removed. I predict "very nearly nothing." Then, to add a deprecation warning for when it is used, with a drop dead date. That is, assuming that we don't realize there's some reason we really ought not to do this.
>
> This is a low-value win, but I think it's a win. Shall we carry on to RFC this?

I believe this is the most recent disucssion on this topic (2017):
https://github.com/Perl/perl5/issues/16270
Re: removing the old-style package separator [ In reply to ]
On Sun, Aug 15, 2021 at 5:09 AM Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:

> Porters,
>
> Since at least 2009 <http://markmail.org/message/gaux5xx5jlop3vmk>, we
> have been talking, once in a while, about deprecating the use of
> \N{APOSTROPHE} as a package separator, Ada style.
>
> The following two expressions are equivalent:
>
> $x::y::z
>
> $x'y'z
>
>
> This mostly goes unnoticed, but the confusion sometimes seeps in at:
>
> print "This is $user's problem to deal with."
>
> …which attempts to interpolate $user::s
>
> This bites experts and new users alike, and while the apostrophe *might*
> be aesthetically pleasing as a package separator, that battle has basically
> been lost.
>
> I think the next course of action is to see what on CPAN would really
> break if the old package separator was removed. I predict "very nearly
> nothing." Then, to add a deprecation warning for when it is used, with a
> drop dead date. That is, assuming that we don't realize there's some
> reason we really ought not to do this.
>
> This is a low-value win, but I think it's a win. Shall we carry on to RFC
> this?
>
> --
> rjbs
>

As far as I can tell, all the pain relates to quoted strings. I would argue
we should remove them only there, that would have all the benefits without
actually breaking anything.

Leon
Re: removing the old-style package separator [ In reply to ]
On Sun, 15 Aug 2021 13:02:58 +0200
Leon Timmermans <fawaka@gmail.com> wrote:

> As far as I can tell, all the pain relates to quoted strings. I would
> argue we should remove them only there, that would have all the
> benefits without actually breaking anything.

Yes and no.

The trouble with doing that is it would increase the difference in
quoting rules between qq()ed strings and elsewhere.

On Libera/#perl yesterday we encountered a new one that nobody seemed
to be previously aware of:

eval: my $x = "scalar"; my @x = ("array"); [ $x[0], ${x}[0], "$x[0]", "${x}[0]" ]

[ 'array', 'array', 'array', 'scalar[0]' ]

Notice how the braces of `${var}[0]` act differently inside qq()ed
strings as compared without.

I'm not sure I'd like making ' act in a similarly inconsistent way
between these two places.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: removing the old-style package separator [ In reply to ]
I suggested that a first step to remove the old package separator could be to forbid it in variable names. Subroutine names like don?t would still be allowed, but $a?b would not. Since it can no longer appear in variable names, the problem of doublequoted strings goes away.

I am quite in favour of removing it altogether, but I recognize that subroutine calls with ? exist in the wild, so this might be a less disruptive first step. I think that it is simpler and less confusing to just forbid ? in variable names than to change the behaviour of doublequoted strings while continuing to allow ? everywhere else.

(please ignore confidentiality stuff below here)
________________________________
De: Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
Enviado: Sunday, August 15, 2021 2:18:50 PM
Para: Leon Timmermans <fawaka@gmail.com>
Cc: Ricardo Signes <perl.p5p@rjbs.manxome.org>; Perl 5 Porters <perl5-porters@perl.org>
Asunto: Re: removing the old-style package separator

On Sun, 15 Aug 2021 13:02:58 +0200
Leon Timmermans <fawaka@gmail.com> wrote:

> As far as I can tell, all the pain relates to quoted strings. I would
> argue we should remove them only there, that would have all the
> benefits without actually breaking anything.

Yes and no.

The trouble with doing that is it would increase the difference in
quoting rules between qq()ed strings and elsewhere.

On Libera/#perl yesterday we encountered a new one that nobody seemed
to be previously aware of:

eval: my $x = "scalar"; my @x = ("array"); [ $x[0], ${x}[0], "$x[0]", "${x}[0]" ]

[ 'array', 'array', 'array', 'scalar[0]' ]

Notice how the braces of `${var}[0]` act differently inside qq()ed
strings as compared without.

I'm not sure I'd like making ' act in a similarly inconsistent way
between these two places.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmetacpan.org%2Fauthor%2FPEVANS&amp;data=04%7C01%7Ced.avis%40qmaw.com%7C9142d32e22934d7756af08d95fe6e57c%7Cd8fde2f5939242608a030ad01f4746e9%7C0%7C0%7C637646267567589404%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=CrzP8X7ezfXhSuCo6B2fvjqTTf1%2BVDrNBfa%2FvQkST1w%3D&amp;reserved=0
https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.leonerd.org.uk%2F&amp;data=04%7C01%7Ced.avis%40qmaw.com%7C9142d32e22934d7756af08d95fe6e57c%7Cd8fde2f5939242608a030ad01f4746e9%7C0%7C0%7C637646267567589404%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2BtiagmxgWqO%2FqFBFlKwcAltGrHCW6zbU7Qn9Qth5FWw%3D&amp;reserved=0 | https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.tindie.com%2Fstores%2Fleonerd%2F&amp;data=04%7C01%7Ced.avis%40qmaw.com%7C9142d32e22934d7756af08d95fe6e57c%7Cd8fde2f5939242608a030ad01f4746e9%7C0%7C0%7C637646267567589404%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=4BWPr%2BOwc%2FdJRWJhXCJagZhHcWDQ%2BMS%2Bem1tD9njCXQ%3D&amp;reserved=0

This email and any files transmitted with it are CONFIDENTIAL and are intended solely for the use of the individual(s) or entity to whom they are addressed. Any unauthorised copying, disclosure or distribution of the material within this email is strictly forbidden. Any views or opinions presented within this email are solely those of the author and do not necessarily represent those of PGIM Limited, QMA Wadhwani LLP or their affiliates unless otherwise specifically stated. An electronic message is not binding on its sender. Any message referring to a binding agreement must be confirmed in writing and duly signed. If you have received this email in error, please notify the sender immediately and delete the original. Telephone, electronic and other communications and conversations with PGIM Limited, QMA Wadhwani LLP and/or their associated persons may be recorded and retained. PGIM Limited and QMA Wadhwani LLP are authorised and regulated by the Financial Conduct Authority. PGIM Limited (registered in England No. 3809039) has its registered office at Grand Buildings, 1-3 Strand, Trafalgar Square, London WC2N 5HR and QMA Wadhwani LLP (registered in England No. OC303168) has its registered office at 9th Floor, Orion House, 5 Upper St. Martin's Lane, London, England, WC2H 9EA.

Please note that your personal information may be stored and processed in any country where we have facilities or in which we engage service providers. If you provide personal information to us by email or otherwise, you consent to the transfer of that information to countries outside of your country of residence and these countries may have different data protection rules than your country.

To learn about our privacy policies, please use this link<https://www.pgim.com/disclaimer/privacy-center> to read the Privacy Notices.
Re: removing the old-style package separator [ In reply to ]
On 8/14/21 11:08 PM, Ricardo Signes wrote:
> Porters,
>
> Since at least 2009 <http://markmail.org/message/gaux5xx5jlop3vmk>, we
> have been talking, once in a while, about deprecating the use of
> \N{APOSTROPHE} as a package separator, Ada style.
>

So *that's* where that came from!

[snip]

>
> Shall we carry on to
> RFC this?
>

Yes.
Re: removing the old-style package separator [ In reply to ]
2021-8-15 12:09 Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:

> Porters,
>
> Since at least 2009 <http://markmail.org/message/gaux5xx5jlop3vmk>, we
> have been talking, once in a while, about deprecating the use of
> \N{APOSTROPHE} as a package separator, Ada style.
>
> The following two expressions are equivalent:
>
> $x::y::z
>
> $x'y'z
>
>
> This mostly goes unnoticed, but the confusion sometimes seeps in at:
>
> print "This is $user's problem to deal with."
>
> …which attempts to interpolate $user::s
>
> This bites experts and new users alike, and while the apostrophe *might*
> be aesthetically pleasing as a package separator, that battle has basically
> been lost.
>
> I think the next course of action is to see what on CPAN would really
> break if the old package separator was removed. I predict "very nearly
> nothing." Then, to add a deprecation warning for when it is used, with a
> drop dead date. That is, assuming that we don't realize there's some
> reason we really ought not to do this.
>
> This is a low-value win, but I think it's a win. Shall we carry on to RFC
> this?
>
> --
> rjbs
>

Is this proposal lexical removal using "no feature 'foo'" or global
removal?

Can this be solved with a lexical tokenizer?

If possible, wouldn't it be okay to break nothing?
Re: removing the old-style package separator [ In reply to ]
On Mon, Aug 16, 2021 at 11:51 PM Yuki Kimoto <kimoto.yuki@gmail.com> wrote:

>
> 2021-8-15 12:09 Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
>
>> Porters,
>>
>> Since at least 2009 <http://markmail.org/message/gaux5xx5jlop3vmk>, we
>> have been talking, once in a while, about deprecating the use of
>> \N{APOSTROPHE} as a package separator, Ada style.
>>
>> The following two expressions are equivalent:
>>
>> $x::y::z
>>
>> $x'y'z
>>
>>
>> This mostly goes unnoticed, but the confusion sometimes seeps in at:
>>
>> print "This is $user's problem to deal with."
>>
>> …which attempts to interpolate $user::s
>>
>> This bites experts and new users alike, and while the apostrophe *might*
>> be aesthetically pleasing as a package separator, that battle has basically
>> been lost.
>>
>> I think the next course of action is to see what on CPAN would really
>> break if the old package separator was removed. I predict "very nearly
>> nothing." Then, to add a deprecation warning for when it is used, with a
>> drop dead date. That is, assuming that we don't realize there's some
>> reason we really ought not to do this.
>>
>> This is a low-value win, but I think it's a win. Shall we carry on to
>> RFC this?
>>
>> --
>> rjbs
>>
>
> Is this proposal lexical removal using "no feature 'foo'" or global
> removal?
>
> Can this be solved with a lexical tokenizer?
>
> If possible, wouldn't it be okay to break nothing?
>

This proposal is for deprecation and removal, which would not be lexical as
the parser would subsequently not support it at all.

The alternative proposal of only disabling it within string interpolation
could be a lexical feature. I don't think it's worth the complexity in
either implementation or explaining why it works differently there, when
the only uses of the feature are for jokes.

-Dan
Re: removing the old-style package separator [ In reply to ]
2021-8-17 14:48 Dan Book <grinnz@gmail.com> wrote:

>
> This proposal is for deprecation and removal, which would not be lexical
> as the parser would subsequently not support it at all.
>
> The alternative proposal of only disabling it within string interpolation
> could be a lexical feature. I don't think it's worth the complexity in
> either implementation or explaining why it works differently there, when
> the only uses of the feature are for jokes.
>
> -Dan
>

Although I personally agree with this proposal, Is it possible to tell me
about the Perl version ' is added and the Perl version :: is added for me
to imagine the impact of removal?
Re: removing the old-style package separator [ In reply to ]
On Tue, 17 Aug 2021 15:46:24 +0900, Yuki Kimoto <kimoto.yuki@gmail.com>
wrote:

> 2021-8-17 14:48 Dan Book <grinnz@gmail.com> wrote:
>
> > This proposal is for deprecation and removal, which would not be
> > lexical as the parser would subsequently not support it at all.
> >
> > The alternative proposal of only disabling it within string
> > interpolation could be a lexical feature. I don't think it's worth
> > the complexity in either implementation or explaining why it works
> > differently there, when the only uses of the feature are for jokes.
> >
> > -Dan
>
> Although I personally agree with this proposal, Is it possible to
> tell me about the Perl version ' is added and the Perl version :: is
> added for me to imagine the impact of removal?

The ' is from perl1 .. perl4 and was never removed in perl5

The :: notation was new in perl5 (from the beginning)

--
H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.33 porting perl5 on HP-UX, AIX, and Linux
https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org
Re: removing the old-style package separator [ In reply to ]
2021-8-17 15:58 H.Merijn Brand <perl5@tux.freedom.nl> wrote:

> On Tue, 17 Aug 2021 15:46:24 +0900, Yuki Kimoto <kimoto.yuki@gmail.com>
> wrote:
>
> > 2021-8-17 14:48 Dan Book <grinnz@gmail.com> wrote:
> >
> > Although I personally agree with this proposal, Is it possible to
> > tell me about the Perl version ' is added and the Perl version :: is
> > added for me to imagine the impact of removal?
>
> The ' is from perl1 .. perl4 and was never removed in perl5
>
> The :: notation was new in perl5 (from the beginning)
>
> --
> H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/
> using perl5.00307 .. 5.33 porting perl5 on HP-UX, AIX, and Linux
> https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org
>
>
Thank you.

It seems that we need to send a wide message to users who are running perl
4 as it is.

In my experience, the library jcode.pl seems to use ’ as package separator.
Re: removing the old-style package separator [ In reply to ]
On Tue, 17 Aug 2021 18:05:03 +0900, Yuki Kimoto <kimoto.yuki@gmail.com>
wrote:

> 2021-8-17 15:58 H.Merijn Brand <perl5@tux.freedom.nl> wrote:
>
> > On Tue, 17 Aug 2021 15:46:24 +0900, Yuki Kimoto
> > <kimoto.yuki@gmail.com> wrote:
> >
> > > 2021-8-17 14:48 Dan Book <grinnz@gmail.com> wrote:
> > >
> > > Although I personally agree with this proposal, Is it possible to
> > > tell me about the Perl version ' is added and the Perl version ::
> > > is added for me to imagine the impact of removal?
> >
> > The ' is from perl1 .. perl4 and was never removed in perl5
> >
> > The :: notation was new in perl5 (from the beginning)
>
> Thank you.
>
> It seems that we need to send a wide message to users who are running
> perl 4 as it is.

If there are still active perl4 users, their code does *NOT* have to
change, as perl4 is not going to change. If their users decide to
update their scripts to perl5 (whatever version) not having ' as a
package separator is probably the least of their problems.

Perl4' last release was in Feb 1993, so it is "stable". (and insecure)

> In my experience, the library jcode.pl seems to use ’ as package
> separator.

And what is the target version of perl in that script? What package
does it belong to? When was its latest update? Is it likely that that
script will be updated to use recent perl (if it does not already)?

So, yes, we need to send the message, but perl4 users are not the
target audience

--
H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.33 porting perl5 on HP-UX, AIX, and Linux
https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org
Re: removing the old-style package separator [ In reply to ]
On Tue, Aug 17, 2021 at 06:05:03PM +0900, Yuki Kimoto wrote:
> 2021-8-17 15:58 H.Merijn Brand <perl5@tux.freedom.nl> wrote:
> > The ' is from perl1 .. perl4 and was never removed in perl5
> Thank you.
> It seems that we need to send a wide message to users who are running perl
> 4 as it is.
>
> In my experience, the library jcode.pl seems to use ??? as package separator.

The (used to be) fairly common mirror.pl script, written back in the
middle ages by Lee McLoughlin for mirroring ftp sites, is thoroughly
perl4 code, including calls to eg &ftp'login().

I can't imagine that deapostrophising it would be terribly difficult
though. Of course, with perlbrew being a thing and disks of infinite
size coming free with a packet of corn flakes these days anyone who,
like me, depends on 1990s code with no tests, can just keep a build of
5.32 specially for that one script.

--
David Cantrell | Reality Engineer, Ministry of Information

EINE KIRCHE! EIN KREDO! EIN PAPST!
Re: removing the old-style package separator [ In reply to ]
H.Merijn Brand wrote:
> On Tue, 17 Aug 2021 18:05:03 +0900, Yuki Kimoto <kimoto.yuki@gmail.com>
> wrote:
>>
>> In my experience, the library jcode.pl seems to use ’ as package
>> separator.
>
> And what is the target version of perl in that script? What package
> does it belong to? When was its latest update? Is it likely that that
> script will be updated to use recent perl (if it does not already)?

Jacode is on CPAN and requires Perl v5.5.30:
<https://metacpan.org/dist/Jacode/view/lib/jacode.pl>

I'd be more concerned about Test::More::isn't(), which seems to be one of the very few cases (perhaps the only one?) in which users would intentionally use the old-style separator in new Perl 5 code. But I expect the usual deprecation period will enable basically everyone to handle these cases fine.

+1 on considering this a tiny win.


--
Arne Johannessen
Re: removing the old-style package separator [ In reply to ]
I've very occasionally used Test::More::isn't * -- and I would not mind at
all to change these uses to Test::More::isn_t or ::isnt.

* it isn't (ha!) actually all that useful because normally you want to know
what something *is*, and if it *isn't* a value, it isn't necessarily what
you want it to be (this is the same as why "I got an exception" is a
terrible test -- you really should check that you got the *right*
exception, as it could just as easily be "syntax error in your code" which
ought to result in a failing test) -- so uses are better off changed to
is() or perhaps like().

On Tue, Aug 17, 2021 at 4:15 AM Arne Johannessen <arne-9544@thaw.de> wrote:

> I'd be more concerned about Test::More::isn't(), which seems to be one of
> the very few cases (perhaps the only one?) in which users would
> intentionally use the old-style separator in new Perl 5 code. But I expect
> the usual deprecation period will enable basically everyone to handle these
> cases fine.
>
Re: removing the old-style package separator [ In reply to ]
On Tue, Aug 17, 2021 at 10:15 PM Karen Etheridge <perl@froods.org> wrote:

> I've very occasionally used Test::More::isn't * -- and I would not mind at
> all to change these uses to Test::More::isn_t or ::isnt.
>

When I wrapped (warped?) some Test::More functions for Test::Trap, I
never even looked at Test::More::isn't (and I would have found it a pain to
wrap if I had) – I just used Test::More::isnt straight.

Quoth https://metacpan.org/pod/Test::More#isnt – "For those grammatical
pedants out there, there's an isn't() function which is an alias of isnt()."

Just an alias I'm not even using – I guess I'm not enough of a
grammatical pedant to miss that apostrophe if it goes …

* it isn't (ha!) actually all that useful because normally you want to know
> what something *is*, and if it *isn't* a value, it isn't necessarily what
> you want it to be (this is the same as why "I got an exception" is a
> terrible test -- you really should check that you got the *right*
> exception, as it could just as easily be "syntax error in your code" which
> ought to result in a failing test) -- so uses are better off changed to
> is() or perhaps like().
>

Also a good point. (Grepping through my in-house code and some of my old
employers' code … I haven't even used any of the Test::Trap::*_isnt methods
… I guess I added it to the list of functions to wrap "just because I
could" …)


Eirik
Re: removing the old-style package separator [ In reply to ]
Arne Johannessen <arne-9544@thaw.de> writes:

> I'd be more concerned about Test::More::isn't(), which seems to be one
> of the very few cases (perhaps the only one?) in which users would
> intentionally use the old-style separator in new Perl 5 code. But I
> expect the usual deprecation period will enable basically everyone to
> handle these cases fine.

FWIW, there appear to be about 50 CPAN distributions using `isn't` in a
test: https://grep.metacpan.org/search?q=%5E%5Cs*isn%27t%7Cisn%27t%5Cs*%5B%28%24%40%25%5D&qd=&qft=*.t

vs. over 2000 using `isnt`:
https://grep.cpanauthors.org/search?q=isnt&group_by=distribution&extension=t

- ilmari
Re: removing the old-style package separator [ In reply to ]
2021-8-17 20:15 Arne Johannessen <arne-9544@thaw.de> wrote:

> H.Merijn Brand wrote:
> > On Tue, 17 Aug 2021 18:05:03 +0900, Yuki Kimoto <kimoto.yuki@gmail.com>
> > wrote:
> >>
> >> In my experience, the library jcode.pl seems to use ’ as package
> >> separator.
> >
> > And what is the target version of perl in that script? What package
> > does it belong to? When was its latest update? Is it likely that that
> > script will be updated to use recent perl (if it does not already)?
>
> Jacode is on CPAN and requires Perl v5.5.30:
> <https://metacpan.org/dist/Jacode/view/lib/jacode.pl>
>
>
Thank you for good information.

With this, it seems easy to migrate Perl 4 jcode.pl dependent code to the
new Perl.
Re: removing the old-style package separator [ In reply to ]
On Sat, Aug 14, 2021 at 11:08:40PM -0400, Ricardo Signes wrote:
> The following two expressions are equivalent:
> $x::y::z
>
> $x'y'z

Are we talking about just removing the parsing of "'" in package names in
source code, or more generally the run-time processing of package names,
e.g.

sub a::b { print "a::b called\n" }
my $name = "a'b";
&{$name}();


--
Music lesson: a symbiotic relationship whereby a pupil's embellishments
concerning the amount of practice performed since the last lesson are
rewarded with embellishments from the teacher concerning the pupil's
progress over the corresponding period.
Re: removing the old-style package separator [ In reply to ]
On Mon, 30 Aug 2021 11:31:55 +0100
Dave Mitchell <davem@iabyn.com> wrote:

> On Sat, Aug 14, 2021 at 11:08:40PM -0400, Ricardo Signes wrote:
> > The following two expressions are equivalent:
> > $x::y::z
> >
> > $x'y'z
>
> Are we talking about just removing the parsing of "'" in package
> names in source code, or more generally the run-time processing of
> package names, e.g.
>
> sub a::b { print "a::b called\n" }
> my $name = "a'b";
> &{$name}();

I think the primary motivation was to catch it in string interpolation,
because of the common failures like

print "$name's score is 10\n";

Next up is general static source, and finally symbolic references.
Perhaps it could be attacked in several phases.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: removing the old-style package separator [ In reply to ]
On Mon, Aug 30, 2021, at 6:31 AM, Dave Mitchell wrote:
> On Sat, Aug 14, 2021 at 11:08:40PM -0400, Ricardo Signes wrote:
> > The following two expressions are equivalent:
> > $x::y::z
> >
> > $x'y'z
>
> Are we talking about just removing the parsing of "'" in package names in
> source code, or more generally the run-time processing of package names,

As Paul said, the *primary* motivation was confusion possible in string interpolation, but I think we're better off removing it everywhere, rather than producing more special cases.

--
rjbs

1 2  View All