Front page | perl.perl5.porters |
Postings from February 2017
On Saturday 18 February 2017 06:37:47 Kent Fredric wrote:
> On 18 February 2017 at 03:51, <pali@cpan.org> wrote:
> >
> > That should not break any existing code. And new people who do know what
> > is utf8::is_utf8() doing will stop using it in new code.
> >
> > Idea is that people will stop using utf8::is_utf8() function which has
> > really bad name.
>
>
> This is probably more grounds for a critic policy at this point,
> breaking working code because some people are using it wrong,
> especially over such a large time scale, is not really great.
I do not think this idea will break code. And I do not think code is
really "working". I cannot say that code is "working" or is "correct" if
function has incorrect name...
Adding possible warning or deprecation is something which is happening
in perl and I think in case most of usage is wrong this could be
acceptable solution.
> Especially given you'll have an almost certain chance that somebody
> will "miss the memo" and will blindly go and replace all the use of
> is_utf8 with is_upgraded, not fixing the underlying reason it was
> wrong in the first place ( just like they missed the memo on why using
> is_utf8 in the first place was wrong )
Yes. I agree. But in new code would be new function name and we have a
chance now to assign for it better name. And with better function name
more people would see that such code is broken or at least is doing
something suspicious.
If you do not understand deep detail what those functions are doing you
just read: if scalar is utf8 then encode it to utf8 octets.
if (utf8::is_utf8($scalar) { utf8::encode($scalar) }
That really does not look at the first sight as something wrong. And it
is wrong because of wrong naming!
> I know that sounds like fatalistic "but people will do bad things",
> but given thats exactly the problem we're trying to avoid by renaming
> it here, seems silly to overlook that human limitation :)
It is not silly. With correct naming you can achieve less rate of
misleadings.
> That's why a policy-based approach is probably "more sane", just
> attach documentation to the policy as to what you should be doing and
> why, and then turn on/off the policy as needed. I could have sworn
> there was already a policy for this, but I can't find it *shrug*
>
> The extra bright side of the policy is it serves no point of
> contention from P5P's side of the equation :)
>
>
>
> --
> Kent
>
> KENTNL - https://metacpan.org/author/KENTNL
Thread Previous
|
Thread Next