Rename std.ctype to std.ascii?
Jonathan M Davis
jmdavisProg at gmx.com
Mon Jun 13 18:28:27 PDT 2011
std.ctype is modeled after C's ctype.h. It has functions for operating on
characters - particularly functions which indicate the type of a character (I
believe that ctype stands for character type, so that makes sense). For
instance, isdigit will tell you whether a particular character is a digit. It
only works on ASCII characters (non-ASCII characters return false for
functions like isdigit and functions like toupper do nothing to non-ASCII
characters).
std.uni, on the other hand, operates on characters just like std.ctype does,
but it extends its charter to unicode characters (e.g. it has isUniUpper which
_does_ work on unicode characters, unlike std.ctype's isupper).
The thing is that aside from those familiar with C/C++, most programmers are
likely to find the module name ctype to be rather uniformative. If they're
looking for something like isdigit, they're not terribly likely to go looking
at std.ctype first. And I'm not sure that std.ascii will be all that much more
obvious to them, but it fits in much better with std.uni. std.ascii gets the
character functions which operate only on ASCII characters, and std.uni gets
the character functions which operate on unicode characters in addition to
ASCII characters.
I don't think that the change of module name is enough of an improvement to
merit changing the name just because ctype is arguably bad. However, as it
turns out, _no_ function in std.ctype is properly camelcased, and many of them
return int instead of bool (which the C functions they're modeled after do but
which is not particularly D-like and can cause problems when you actual _need_
them to return bool). And it has been made very clear in past discussions in
this newsgroup that the consensus is that we prefer that Phobos functions
follow Phobos' naming conventions (which means camelcasing) rather than
matching the casing of functions in other languages. So, all of the functions
in std.ctype need to be renamed.
I now have a pull request which creates properly camelcased versions of all of
them ( https://github.com/D-Programming-Language/phobos/pull/101 ). The thing
is though that because _every_ function in std.ctype is renamed, the cost of
renaming the entire module (as far as people updating their code to use
functions such as isDigit instead of isdigit goes) is essentially the same if
as just renaming the functions in-place. In either case, the old functions
will go through the full deprecation process before they're actually gone, so
no one's code will suddenly break because of the changes, but any code that
uses the old functions will eventually have to be change to use the properly
named ones. And since the cost to making those changes is essentially the same
whether we replace the whole std.ctype module or whether we replace all of its
functions, I'm wondering whether it would be worthwhile to take this
opportunity to rename std.ctype?
I don't think that the name change is enough of an improvement to do it if
it's going to break everyone's code, but given that fixing all of its
functions gives us a perfect opportunity to rename it at no additional cost, I
feel that the question should be posed.
Should we rename std.ctype to std.ascii? Or should we just keep the old name,
which is familiar to C programmers?
- Jonathan M Davis
More information about the Digitalmars-d
mailing list