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 21, 2017 17:51
Subject:
Re: Proposal: Rename utf8::is_utf8() to utf8::is_upgraded()
Message ID:
20170221175129.GA17038@pali
On Tuesday 21 February 2017 12:50:16 Sawyer X wrote:
> On 02/21/2017 01:07 AM, Zefram wrote:
> > Kent Fredric wrote:
> >> Though that said, I think we can find a clearer name than "is_upgraded"
> > I think that's the best possible name.  The "upgraded"/"downgraded"
> > terminology for describing the flag state is the only one we have that
> > doesn't give a misleading impression of its significance.  Hence my use
> > of that terminology in Scalar::String.
> 
> What do you think about Leon's suggestion of is_multibyte?

It is bad :-(

Why? Because... first ask: What is utf8::encode() doing? It is
converting string to (UTF-8) octets, so into single byte string. So
people start blindly use construct (because it could make sense):

  if (utf8::is_multibyte($str)) { utf8::encode($str); }

And we have there same again problem.

I proposed name is_upgraded() because we already have functions
upgrade() and downgrade(). And it is fully correct to use construction:

  unless (utf8::is_upgraded($str)) { utf8::upgrade($str); }

Similarly you could write:

  if (utf8::is_upgraded($str)) { utf8::downgrade($str); }

In both cases it just change internal representation of $str which is
invisible in pure perl code. And such construction can be used without
any problem as they are correct. Second one just can die, so eval
handling needs to be used.

If people start using those constructions there will be less broken
code.

So for me usage of is_upgraded() fits better into already used names
upgrade() and downgrade().

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