New std.uni: ready for more beating

[Jonathan M Davis]

On Tuesday, February 26, 2013 08:40:02 Jacob Carlborg wrote:
> On 2013-02-26 08:34, Jonathan M Davis wrote:
> > Well, it can get pretty bad with module names when you're forced to give
> > the full import path. For instance, std.string, std.ascii, and std.uni
> > all have toLower, and std.unicode.toLower is definitely longer than
> > std.uni.toLower.
> If you think that "std.unicode.toLower" is too long then create an alias
> for it.
> 
> BTW, I don't think it's fair to use the fully qualified name when
> comparing. Then we can never have a nested package hierarchy in Phobos
> or we will get names looking like:
> 
> std.a.b.c.d

It's still something that needs to be considered. Having overly long names 
_will_ create problems, as will overly short names. A balance is needed. Fully 
qualified names just show one of the costs to longer names. Picking good names 
is a bit of an art. Going the C route of overly short names is a mistake as is 
going the Java route of overly descriptive ones.

In the case of std.uni vs std.unicode, I probably would agree that std.unicode 
is better, because it's more destriptive, whereas std.uni is arguably not 
descriptive enough as nice as its length may be. So, if we were starting from 
scratch, std.unicode would make more sense. However, as we're not starting 
from scratch, and switching to std.unicode would break a lot of code, it's not 
worth switching to std.unicode just for a more descriptive name. It would be a 
good choice if we had to change the name for other reasons (e.g. the API 
needed to be changed in a non-backwards-compatible manner), but improving the 
name isn't a good enough reason.

- Jonathan M Davis