On Tue Aug 30 01:27:21 2016, SREZIC wrote:
Show quoted text> Compilation fails with bleadperl (e.g. perl 5.25.4):
>
> # Failed test 'use Lingua::SWE::Word2Num;'
> # at t/Word2Num.t line 21.
> # Tried to use 'Lingua::SWE::Word2Num'.
> # Error: The encoding pragma is no longer supported at
> /tmpfs/.cpan-build-cpansand/2016082921/Lingua-SWE-Word2Num-0.0682-
> 0/blib/lib/Lingua/SWE/Word2Num.pm line 16.
> # BEGIN failed--compilation aborted at /tmpfs/.cpan-build-
> cpansand/2016082921/Lingua-SWE-Word2Num-0.0682-
> 0/blib/lib/Lingua/SWE/Word2Num.pm line 16.
> # Compilation failed in require at t/Word2Num.t line 21.
> # BEGIN failed--compilation aborted at t/Word2Num.t line 21.
> Attempt to reload Lingua/SWE/Word2Num.pm aborted.
> Compilation failed in require at t/Word2Num.t line 25.
> BEGIN failed--compilation aborted at t/Word2Num.t line 25.
> # Tests were run but no plan was declared and done_testing() was not
> seen.
> # Looks like your test exited with 255 just after 1.
> t/Word2Num.t ..
> Dubious, test returned 255 (wstat 65280, 0xff00)
> Failed 1/1 subtests
One of the reasons for deprecating the encoding pragma was that the same sequence of logical characters would be treated completely differently depending on the internal encoding.
For example, you could have two strings for which ord(substr $str, $n) returns the same values for every $n, but for which ‘eq’ returns false!
Because this module uses ‘use encoding 'utf8'’, the caller cannot pass, say, "\xE5tta", because it gets silently converted to "\x{fffd}tta", whereas if the caller writes "\N{U+E5}tta" it works correctly, the same way it would have if the caller wrote ‘use utf8; "åtta"’.
It also happens that "\xc3\xa5tta" will work and be silently converted to "\N{U+E5}tta"; i.e., the ordinal values of the logical characters in the string will change magically and somewhat unpredictably.
Since encoding.pm support has been removed from the perl core, that automatic change in the representation of the string will stop happening.
It is up to the author of the module to decide exactly how this should be dealt with. Should both of these still be accepted as valid input values, as previously?
"\xc3\xa5tta"
"\N{U+E5}tta"
If that is the case, then the module will have to utf8::decode($its_input), which may fail harmlessly, in which case the string is already in the latter form.
Alternatively, support for the former string could simply be dropped. That would require simply changing ‘use encoding 'utf8'’ to ‘use utf8’. (In either case, ‘use utf8’ is appropriate.)
