Naming conventions for functions in similar modules

Jonathan M Davis jmdavisProg at gmx.com
Wed Jun 22 14:05:42 PDT 2011


On 2011-06-22 13:34, Timon Gehr wrote:
> Lars T. Kyllingstad wrote:
> > On Wed, 22 Jun 2011 09:53:39 -0700, Walter Bright wrote:
> >> On 6/22/2011 4:47 AM, Lars T. Kyllingstad wrote:
> >>> One problem: std.uni only contains functions for dealing with upper/
> >>> lower case and for checking whether something is an alpha character.
> >>> If you want the other functions, such as isDigit(), isPunctuation(),
> >>> etc. you still have to import std.ascii. And once you have imported
> >>> both std.uni and std.ascii, you are forced to disambiguate every time
> >>> you call a function which exists in both.
> >> 
> >> True, but I don't see much of an improvement of:
> >> toAsciiLower()
> >> 
> >> over:
> >> std.ascii.tolower()
> >> 
> >> at least as far as typing goes.
> > 
> > I agree with that. My point was that maybe std.unit should also have
> > functions such as isDigit(), isPunctuation() etc. I suppose we want to
> > encourage the use of std.uni over std.ascii in most cases, since D is
> > supposed to handle Unicode out of the box.
> > 
> > -Lars
> 
> I guess then we'll also need a function to check for equivalence of two
> Unicode strings.

As in dealing with unicode normalization? The whole grapheme issue has yet to 
be sorted out. Presumably, we'll have some sort of grapheme-based range 
eventually, and we'll probably end up with a unicode normalization function 
for normal strings eventually. But with everything that there is to do, who knows 
when they'll be done. I don't think that there's any question that we want D 
to be top notch when it comes to dealing with unicode. It's just a matter of the
time,  manpower, and knowledge necessary to do it. So, it'll happen, but I have
no idea when.

- Jonathan M Davis


More information about the Digitalmars-d mailing list