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:
Leon Timmermans
Date:
February 21, 2017 22:15
Subject:
Re: Proposal: Rename utf8::is_utf8() to utf8::is_upgraded()
Message ID:
CAHhgV8jfzfo5uLNOWeM0dnJ14e3Gva9Yo1k00bFbPGuG0SA54w@mail.gmail.com
On Tue, Feb 21, 2017 at 6:51 PM, <pali@cpan.org> wrote:
>
> 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().

That is a good point, even if neither example is really sensible
(upgrading or downgrading unconditionally achieves exactly the same;
they're sensible like that).

Part of me feels like this should have been very dehuffmanized (e.g.
internal_representation_upgraded), but given there's already a short
alias that may not be useful anymore.

Leon

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