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
