Front page | perl.perl5.porters |
Postings from February 2017
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