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.Thread Previous | Thread Next