develooper Front page | perl.perl5.porters | Postings from July 2017

Re: [perl #131685] Rename utf8::is_utf8() (and other functions)

Thread Previous | Thread Next
July 10, 2017 20:13
Re: [perl #131685] Rename utf8::is_utf8() (and other functions)
Message ID:
Sawyer X wrote:
>Does anyone have any comments on this? Tony, Dave, Zefram? *Karl*? :)

I didn't want to add to a mostly bikeshedding discussion, but OK.
I concur that the existing names are poor, but I'm not much happier with
the names that have been suggested on this thread.  I reckon the best
terminology we have for this flag, at the user level, is "upgraded",
and so the name "is_utf8" would be better as "is_upgraded".  The existing
names "upgrade" and "downgrade" for the transforming operations are OK,
and the only change I'd potentially like to make to them would be to add
something that explicates their rather unusual in-place side-effecting

In fact you can see all my preferred names in my CPAN module
Scalar::String.  This module essentially attempts to be the sane version
of, attempting to impart the right mental model through its
function names and documentation.  (The "sclstr_" prefix on all the
function names may be omitted if desired; the important part of the name
is that which distinguishes these functions from each other.)

I think the names for these functions should be reasonably concise,
and in particular we should have a single-word adjective for "having
the SvUTF8 flag on" if possible.  We should also try to reuse existing
terminology, rather than invent anything new.  We should also avoid any
term that implies anything beyond the storage, such as any reference to
characters or Unicode, because such implications are largely inaccurate,
and anywhere they are accurate is a bug.  All of this leads me to prefer
"upgraded" over "utf8", "unicode", "uses_wide_storage", and the like.

I don't have any strong opinion about which package any new names for
these functions should appear in.  I think on balance we should not
remove the old names, because the trouble that arises from maintaining
them is small compared to the hassle that would arise from requiring
existing correct programs to change.  Not removing them implies that
we wouldn't even be deprecating them, as currently defined, but we can
fairly discourage the use of the old names in documentation.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About