FAQ
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.

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.

Search Discussions

  • Aristotle Pagaltzis at May 25, 2016 at 7:01 pm

    * Father Chrysostomos [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/>
  • Father Chrysostomos at May 25, 2016 at 8:05 pm

    Aristotle wrote:
    * Father Chrysostomos [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?
    I do not know of any other source filter module that provides this.
    If we are going to stop ${^ENCODING} from working, it might be a
    good idea to provide such a source filter module in core. And, hey,
    we have one. If that were not so, I would have proposed one instead.
    That's the real reason for this thread.

    (Similarly, I think it was a Bad Idea for 5.10 to ship with $* dis-
    abled, but with no replacement. The latter did not arrive until
    5.14.0 provided use re '/flags'.)
    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.
    The main reason the removal from the core was brought up was in
    response to the complaints about how broken encoding.pm is, specific-
    ally because of how broken ${^ENCODING} is. Hence, perhaps it was not
    thought through.

    Maybe I should have said this at the time, but I do not think we
    accomplish anything by removing encoding.pm from the core, except to
    give somebody more work to do.

    encoding.pm itself is not deprecated per se, but only its use on perl
    versions in which the underlying functionality is deprecated. Until
    Encode.pm drops support for 5.22, encoding.pm can continue to be
    shipped with it, and, consequently, with perl. Anything else is more
    work than necessary.
  • Kent Fredric at May 25, 2016 at 9:54 pm

    On 26 May 2016 at 08:05, Father Chrysostomos wrote:
    If we are going to stop ${^ENCODING} from working, it might be a
    good idea to provide such a source filter module in core.

    I thought the criteria for continued inclusion in core was more
    "needed for bootstrap"?

    If its not needed directly or indirectly for bootstrapping to CPAN,
    then I don't think "it /might/ be a good idea to have in core" is a
    strong enough justification.
    Anything else is more work than necessary.
    Continued inclusion of encoding.pm in core means continued debate over
    its feature set, and continued requirement to mitigate bugs it raises
    in future Perl releases, and continued slowing of development of both
    Perl and encoding.pm by their union.

    Of course, unbundling encoding will have short term energy costs due
    to possible proliferation of code that uses it, but does not depend on
    it, but if that's a cost we'll have to pay eventually....

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-porters @
categoriesperl
postedMay 22, '16 at 9:17p
activeMay 25, '16 at 9:54p
posts4
users3
websiteperl.org

People

Translate

site design / logo © 2018 Grokbase