On Sat, May 31, 2014 at 09:54:50PM +0200, Brian Fraser wrote:
First of all, this is documented syntax in 5.18, and I don't see it
deprecated anywhere in perlvar (which documents this variable name
perldata, under "Identifier parsing".
Hmm, it doesn't seem to be in my version of that manpage. In fact,
perldata says, in that section:

  A sigil, followed by either a caret and a single POSIX uppercase letter,
  like $^V or $^W, or a sigil followed by a literal control character
  matching the "\p{POSIX_Cntrl}" property.

In any case, perldata is entirely the wrong manpage (it's about perl data
types - variable names are not a data type. If anywhere, it should be in
perlsyn, and certainly perlvar needs to be updated).
Secondly, I don't see why an existing warning category is
changed, again, in a backwards-incompatible way.
I don't follow. It's a new deprecation warning under the 'deprecated'
category. Are you saying that p5p shouldn't add new warnings to
existing categories? Or add new default categories..?
I think p5p should follow the official policy on backwards compatibility,
or change the policy to be more honest, as in "we do not care about
compatibility anymore", which, while not entirely correct, matches reality
far better than the current wording.

I can provide a patch for the wording. At least, people would then know
they can't rely on perl keeping backwards compatibility and the mentioned
madness has finally caught on.

As for the actual deprecation, obviously this syntax shouldn't be
deprecated in the first place, as it doesn't hurt anybody and there is
no demonstrated need for change (so it's the worst change possible). The
reasonable and backwards-compatible way would be to add a new warning
category for this, as is done with other language constructs that can
be potential pitfalls to some people (such as use of "undef", which
fortunately isn't deprecated either).
Lately, ignoring or actively opposing compatibility with earlier versions
of Perl has come into vogue.
Reasoning for this deprecation is here:
Well, if you read through it, it seems this worked in 5.12.4 and broke in
5.17 (according to the original report).

I don't see any sensible arguments or reasoning in there, either. The
original report basically argues that, since EBCDIC has a different idea of
literal control characters, it should be broken for non-EBCDIC platforms as
well, which is clearly unreasonable.

It goes on like this:

    Fully support that deprecation. +1
    This will break one of my programs. I say go for it :-)

and so on, followed by discussion on how to break it best.

Infact, this is the perfect illustration of the mindset at work here: it
breaks existing scripts, go for it, other arguments not required! There
are absolutely zero arguments for deprecating this feature in there (as
oppposed to e.g. ading a new warning for it, as e.g. done for undef).

If anything, this actually reinforces what I wrote and quoted before.

                 The choice of a Deliantra, the free code+content MORPG
       -----==- _GNU_ http://www.deliantra.net
       ----==-- _ generation
       ---==---(_)__ __ ____ __ Marc Lehmann
       --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
       -=====/_/_//_/\_,_/ /_/\_\

Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2021 Grokbase