develooper Front page | perl.perl5.porters | Postings from February 2017

Re: Proposal: Rename utf8::is_utf8() to utf8::is_upgraded()

Thread Previous | Thread Next
From:
pali
Date:
February 20, 2017 08:47
Subject:
Re: Proposal: Rename utf8::is_utf8() to utf8::is_upgraded()
Message ID:
20170220084733.GB24022@pali
On Sunday 19 February 2017 07:59:58 Karl Williamson wrote:
> On 02/17/2017 10:37 AM, 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.
> >
> >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 )
> >
> >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 :)
> >
> >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 :)
> >
> 
> I think it is a good idea to at least give people an opportunity to have a
> name that doesn't mislead, even if we keep the old name for back
> compatibility.  I've done that several times in the core.  The problem with
> a misleading name is that it, well, misleads.  Even if you know about it, in
> skimming code, you can be misled.
> 
> So, I support adding a synonym.

+1

Now I'm thinking if is_utf8() function should be rather in Internals
package, like Internals::SvREADONLY(). It is doing similar thing,
returns state of some internal perl scalar flag.

If you see that code is calling function named Internals::something()
then it is more suspicious as if is calling utf8::is_utf8(). And more
people could start thinking if such code is really correct.

Also functions utf8::upgrade(), utf8::downgrade() and utf8::valid() are
looks like they could be in Internals. utf8::valid() is already marked
as internal in documentation.

Basically all those functions are not needed in pure perl code and I
think they are used either when testing XS modules or dealing with bugs in
XS modules or are incorrectly used.

But if throwing warnings on usage or deprecation is no-go. What about at
least add new alias (either in utf8 or Internals package) with better
name and write in documentation to starts using new preferred name?

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