develooper Front page | perl.perl5.porters | Postings from May 2016

Re: Maybe only partially deprecate encoding.pm?

Thread Previous | Thread Next
From:
Aristotle Pagaltzis
Date:
May 25, 2016 19:01
Subject:
Re: Maybe only partially deprecate encoding.pm?
Message ID:
20160525190112.GA62025@plasmasturm.org
* Father Chrysostomos <sprout@cpan.org> [2016-05-23 00:11]:
> encoding.pm has a Filter option which, instead of hooking the upgrad-
> ing of strings, simply runs the source of the file through a decoding
> source filter and does an effective 'use utf8'. This option actually
> makes sense and follows a sane model.

Does it offer anything you can’t do with some other source filter helper
module?

> Currently encoding.pm emits a deprecation warning on any ->import.
> Should it perhaps only emit such a warning when using ${^ENCODING}? It
> is the latter, after all, which we are trying to removed, because of
> the problems it causes.

I have no idea what has been done about it, but I’ll note that there are
two separate issues, which may (I don’t know) be getting conflated here,
because of the unfortunate confusion of terminology for module removals.

One is deprecation in the sense of “we will stop shipping this in core,
if you need it then please install it from CPAN from now on”.

Another is deprecation in the sense of “this will stop working at all,
please change your code accordingly”.

The latter applies to ${^ENCODING} alone, the former to encoding.pm as
a whole. And if you are talking about ${^ENCODING} alone, then I agree.
But the plan to remove it from core ought to proceed apace.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About