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