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