www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - little thing - D and phobos naming conventions

reply Brian Hay <bhay construct3d.com> writes:
I'm new to D so please forgive my ignorance if indeed that's what it is.

One thing I like about C#.NET and Java is the consistency and 
readability of language keywords and framework classes and methods etc, 
despite the extra verbosity. These languages conform to strict, verbose 
naming conventions e.g. upper camel case for classes, lower camel case 
for methods and variables.

Having said that, I still prefer D (and the development philosophy 
behind it) but, for example, some library method names are inconsistent 
and mostly (but not always) follow the legacy C/C++ conventions of 
lowercase everything and abbreviate to sometimes incoherent acronyms 
wherever possible. I think this makes code less readable, but I know 
this is a subjective opinion.


Example inconsistencies:

   phobos.std.string

     toSting() (lower camel case)
     tolower() (all lower case)

     iswhite() (all lower case)
     isNumeric() (lower camel case)
     inPattern() (lower camel case)

     tr() not immediately clear what these abbreviations mean
     atoi() what is the aversion to a little more verbosity?


Other than the "D Style Guide" doc for coders (which phobos doesn't seem 
to conform to), is there a particular naming convention for the D 
language and standard libraries themselves and what is the rationale 
behind it? (I'm presuming it's to make the language more familiar to 
C/C++ coders)

Everything else about D is so cool, modern, well-designed and 
cutting-edge but some of this naming is so "old school". I know I'm 
being anal and this shouldn't get on my nerves ... but alas it does.


Brian.
Oct 27 2006
next sibling parent reply AF <noemail noemail.com> writes:
 Maybe isn't very well said, but I find no reason for the
name "std.stdio". Yes, for "std.c.stdio", it was ok, but in the d-
written phobos... "std.io" isn't easier?
 Anyway, is just a little thing. I can stand with it.

 AF
Oct 27 2006
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
AF wrote:
  Maybe isn't very well said, but I find no reason for the
 name "std.stdio". Yes, for "std.c.stdio", it was ok, but in the d-
 written phobos... "std.io" isn't easier?
  Anyway, is just a little thing. I can stand with it.

This has been discussed before. IIRC, the rationale was 'stdio' refers to the standard input/output provided by the operating system (i.e. console i/o, by default). Though std.stdio also seems to contain FILE* i/o, so maybe the name isn't _entirely_ appropriate.
Oct 27 2006
next sibling parent reply Wolfgang Draxinger <wdraxinger darkstargames.de> writes:
Frits van Bommel wrote:

 Though std.stdio also seems to contain FILE* i/o, so maybe the
 name isn't _entirely_ appropriate.

On the majority of operating systems the stdio (console) is implemented with files, so it's there by design. Wolfgang Draxinger -- E-Mail address works, Jabber: hexarith jabber.org, ICQ: 134682867 GPG key FP: 2FC8 319E C7D7 1ADC 0408 65C6 05F5 A645 1FD3 BD3E
Oct 27 2006
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Wolfgang Draxinger wrote:
 Frits van Bommel wrote:
 
 Though std.stdio also seems to contain FILE* i/o, so maybe the
 name isn't _entirely_ appropriate.

On the majority of operating systems the stdio (console) is implemented with files, so it's there by design.

I know, it's also what writef(ln) use internally, they just provide the first parameter as 'stdout'. I just thought that maybe it should (privately) import another module for that instead of containing the functions themselves.
Oct 27 2006
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Frits van Bommel wrote:

 This has been discussed before. IIRC, the rationale was 'stdio' refers 
 to the standard input/output provided by the operating system (i.e. 
 console i/o, by default).
 Though std.stdio also seems to contain FILE* i/o, so maybe the name 
 isn't _entirely_ appropriate.

And it's even more funny as stdio doesn't contain any "input"... But I guess that "std.stdo" would have sounded more strange :-) --anders
Oct 27 2006
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Anders F Björklund wrote:
 Frits van Bommel wrote:
 
 This has been discussed before. IIRC, the rationale was 'stdio' refers 
 to the standard input/output provided by the operating system (i.e. 
 console i/o, by default).
 Though std.stdio also seems to contain FILE* i/o, so maybe the name 
 isn't _entirely_ appropriate.

And it's even more funny as stdio doesn't contain any "input"...

Yeah, that too :).
 But I guess that "std.stdo" would have sounded more strange :-)

Well, at least it leaves room for expansion :). What do you think, should Object get a method 'fromString' or something so we can add something like readf(ln) to std.stdio? ;)
Oct 27 2006
parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
Frits van Bommel wrote:
 Anders F Björklund wrote:
 
 Frits van Bommel wrote:

 This has been discussed before. IIRC, the rationale was 'stdio' 
 refers to the standard input/output provided by the operating system 
 (i.e. console i/o, by default).
 Though std.stdio also seems to contain FILE* i/o, so maybe the name 
 isn't _entirely_ appropriate.

And it's even more funny as stdio doesn't contain any "input"...

Yeah, that too :).
 But I guess that "std.stdo" would have sounded more strange :-)

Well, at least it leaves room for expansion :). What do you think, should Object get a method 'fromString' or something so we can add something like readf(ln) to std.stdio? ;)

We shouldn't even need that to get some kind of readln() function. Make it simple, it shouldn't need arguments (overload though for the fancy stuff) just read a line from the console. Later on if we want fromString, so we can do more fancy formatted input and stuff, ok, but for now I am kinda dissappointed with the /complete/ lack of console input function in phobos (disregarding std.c, because that's c not d and a pain to use IMO). I do miss a cheap/easy way to grab input like in C# w/ Console.ReadLine().
Oct 27 2006
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Chad J" <gamerChad _spamIsBad_gmail.com> wrote in message 
news:ehuhhr$29gk$1 digitaldaemon.com...

 We shouldn't even need that to get some kind of readln() function.  Make 
 it simple, it shouldn't need arguments (overload though for the fancy 
 stuff) just read a line from the console.

 Later on if we want fromString, so we can do more fancy formatted input 
 and stuff, ok, but for now I am kinda dissappointed with the /complete/ 
 lack of console input function in phobos (disregarding std.c, because 
 that's c not d and a pain to use IMO).

 I do miss a cheap/easy way to grab input like in C# w/ Console.ReadLine().

how about import std.cstream; ... int x; float y; din.readf("%d %f", &x, &y); ? I agree, this should be available in std.stdio, but..
Oct 27 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Jarrett Billingsley wrote:

I do miss a cheap/easy way to grab input like in C# w/ Console.ReadLine().

how about

 din.readf("%d %f", &x, &y);
 
 ?

It still doesn't work in GDC, though: din.readf("%d %f", &x, &y); dout.writef("%d %f", x, y); 3 3.14 0 nan And I really don't like the din/dout.
 I agree, this should be available in std.stdio, but.. 

It really should. And "writeln" too. The alternative libraries work, but. --anders
Oct 28 2006
prev sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Chad J wrote:
 Frits van Bommel wrote:
 Anders F Björklund wrote:

 Frits van Bommel wrote:

 This has been discussed before. IIRC, the rationale was 'stdio' 
 refers to the standard input/output provided by the operating system 
 (i.e. console i/o, by default).
 Though std.stdio also seems to contain FILE* i/o, so maybe the name 
 isn't _entirely_ appropriate.

And it's even more funny as stdio doesn't contain any "input"...

Yeah, that too :).
 But I guess that "std.stdo" would have sounded more strange :-)

Well, at least it leaves room for expansion :). What do you think, should Object get a method 'fromString' or something so we can add something like readf(ln) to std.stdio? ;)

We shouldn't even need that to get some kind of readln() function. Make it simple, it shouldn't need arguments (overload though for the fancy stuff) just read a line from the console. Later on if we want fromString, so we can do more fancy formatted input and stuff, ok, but for now I am kinda dissappointed with the /complete/ lack of console input function in phobos (disregarding std.c, because that's c not d and a pain to use IMO). I do miss a cheap/easy way to grab input like in C# w/ Console.ReadLine().

You should look at Ares + Mango. IO is very well implemented.
Oct 27 2006
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
Brian Hay wrote:
 I'm new to D so please forgive my ignorance if indeed that's what it is.
 
 One thing I like about C#.NET and Java is the consistency and 
 readability of language keywords and framework classes and methods etc, 
 despite the extra verbosity. These languages conform to strict, verbose 
 naming conventions e.g. upper camel case for classes, lower camel case 
 for methods and variables.
 
 Having said that, I still prefer D (and the development philosophy 
 behind it) but, for example, some library method names are inconsistent 
 and mostly (but not always) follow the legacy C/C++ conventions of 
 lowercase everything and abbreviate to sometimes incoherent acronyms 
 wherever possible. I think this makes code less readable, but I know 
 this is a subjective opinion.
 
 
 Example inconsistencies:
 
   phobos.std.string
 
     toSting() (lower camel case)
     tolower() (all lower case)
 
     iswhite() (all lower case)
     isNumeric() (lower camel case)
     inPattern() (lower camel case)
 
     tr() not immediately clear what these abbreviations mean
     atoi() what is the aversion to a little more verbosity?

This is largely a result of the naming convention evolving over time, and portions of Phobos being somewhat old. Phobos code should indeed follow the D Style Guide.
 Other than the "D Style Guide" doc for coders (which phobos doesn't seem 
 to conform to), is there a particular naming convention for the D 
 language and standard libraries themselves and what is the rationale 
 behind it? (I'm presuming it's to make the language more familiar to 
 C/C++ coders)

Not really. Note that some libraries have adopted a somewhat modified form. Mango CamelCases module names, for example. I've been talking to Kris a bit recently and we've been working towards formalizing the convention a bit, but we have yet to put it into writing.
 Everything else about D is so cool, modern, well-designed and 
 cutting-edge but some of this naming is so "old school". I know I'm 
 being anal and this shouldn't get on my nerves ... but alas it does.

Consistency is rarely a bad thing in programming :-) Sean
Oct 27 2006
prev sibling parent Chad J <gamerChad _spamIsBad_gmail.com> writes:
Brian Hay wrote:
 I'm new to D so please forgive my ignorance if indeed that's what it is.
 
 One thing I like about C#.NET and Java is the consistency and 
 readability of language keywords and framework classes and methods etc, 
 despite the extra verbosity. These languages conform to strict, verbose 
 naming conventions e.g. upper camel case for classes, lower camel case 
 for methods and variables.
 
 Having said that, I still prefer D (and the development philosophy 
 behind it) but, for example, some library method names are inconsistent 
 and mostly (but not always) follow the legacy C/C++ conventions of 
 lowercase everything and abbreviate to sometimes incoherent acronyms 
 wherever possible. I think this makes code less readable, but I know 
 this is a subjective opinion.
 
 
 Example inconsistencies:
 
   phobos.std.string
 
     toSting() (lower camel case)
     tolower() (all lower case)
 
     iswhite() (all lower case)
     isNumeric() (lower camel case)
     inPattern() (lower camel case)
 
     tr() not immediately clear what these abbreviations mean
     atoi() what is the aversion to a little more verbosity?
 
 
 Other than the "D Style Guide" doc for coders (which phobos doesn't seem 
 to conform to), is there a particular naming convention for the D 
 language and standard libraries themselves and what is the rationale 
 behind it? (I'm presuming it's to make the language more familiar to 
 C/C++ coders)
 
 Everything else about D is so cool, modern, well-designed and 
 cutting-edge but some of this naming is so "old school". I know I'm 
 being anal and this shouldn't get on my nerves ... but alas it does.
 
 
 Brian.

uh, too true. I'd really love to see a release of phobos that has all of these inconsistancies fixed, and while we're at it let's fix the death-by-abbreviation names too. I'm pretty much willing to not only rewrite my own code, but other peoples' too.
Oct 27 2006