On Tue, 21 May 2013 13:51:01 +0100, Dmitry Olshansky
<[email protected]> wrote:
The pitch by deadalnix:
I strongly push into renaming it to std.unicode . As said in the other
thread : uni can be unicode, but also unique, union, unit, uniform,
unix, unijambist, whatever.
When theses pile up in a large library, this is more and more difficult
to rely on intuition/autocompletion and much more on programmer's
memory. It mean that it takes longer to learn the whole library.
My reservations:
If the chief benefit of renaming is aesthetics then I'd rather pass.
It's not aesthetics. It's to make it clear what the module is/does. I
read std.uni again recently, after being "away" from D for a while and
briefly wondered what "uni" stood for, I loaded the docs and it was clear
.. but that initial doubt was still there. Had it been called std.unicode
I would have known without looking.
This kind of knee-jerk changes made on basis of "a good time to try to
push a better name" just don't belong in design of library/package
structure. Yeah, I know nobody is going to say "package structure"
looking at Phobos.
True.
If we make it a part of restructuring std.* that is long overdue then
I'm fine as long as package structure is well thought out as a whole.
Good structure can come about from a complete top down design.. but also
from many small changes towards a better whole. This is perhaps one such
change?
Changing it now before adopting a package structure risks the 2nd change
and another set of arguments for keeping things as is.
Are we ever going to have a complete restructuring? I doubt it.. Meaning
if we can make an incremental change for the better now when there is some
obviation of the resulting issues then we should, or we risk more
resistance in the future.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
