New std.uni: ready for more beating

Jonathan M Davis jmdavisProg at gmx.com
Wed Feb 27 15:17:29 PST 2013


On Wednesday, February 27, 2013 22:07:04 Jacob Carlborg wrote:
> On 2013-02-26 21:13, Jonathan M Davis wrote:
> > Really? There are a few (particularly older ones), but for the most part,
> > I'd argue that that's not the case at all. In general, IMHO, Phobos does
> > an excellent job of having function names that are reasonably descriptive
> > and are of a reasonable length. And, if anything, we tend to err on the
> > side of being too long (e.g. ElementEncodingType).
> > 
> > - Jonathan M Davis
> 
> These are just a couple:
> 
> std.string
> icmp
> makeTrans
> succ
> abbrev
> 
> std.array
> assocArray
> 
> std.file
> isDir
> attrIsDir
> attrIsFile
> attrIsSymlink
> dirEntries
> 
> std.uni
> lineSep
> paraSep
> 
> std.datetime
> currTime
> Every member of the Month, DayOfWeek and Direction enums.
> fracSec

And in almost all cases, I see nothing to complain about here. Most of them 
are quite clear as they are. Making them longer would just make them longer to 
no real benefit IMHO, and it _would_ be adding a cost. You seem to think that 
abbreviations are bad, and I completely disagree. IMHO, a symbol name should 
be as long as it needs to be in order to be clear and no longer, and as long 
as an abbreviation is clear, then it's great to use it. But if you have 
problems with most of those names, then I think that it's pretty clear that 
we're just going to have to agree to disagree on this, because for the most 
part, I think that they're great as they are.

- Jonathan M Davis


More information about the Digitalmars-d mailing list