digitalmars.D - little thing - D and phobos naming conventions
- Brian Hay (30/30) Oct 27 2006 I'm new to D so please forgive my ignorance if indeed that's what it is.
- AF (5/5) Oct 27 2006 Maybe isn't very well said, but I find no reason for the
- Frits van Bommel (6/10) Oct 27 2006 This has been discussed before. IIRC, the rationale was 'stdio' refers
- Wolfgang Draxinger (7/9) Oct 27 2006 On the majority of operating systems the stdio (console) is
- Frits van Bommel (5/12) Oct 27 2006 I know, it's also what writef(ln) use internally, they just provide the
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (4/9) Oct 27 2006 And it's even more funny as stdio doesn't contain any "input"...
- Frits van Bommel (5/15) Oct 27 2006 Well, at least it leaves room for expansion :).
- Chad J (9/32) Oct 27 2006 We shouldn't even need that to get some kind of readln() function. Make...
- Jarrett Billingsley (10/18) Oct 27 2006 how about
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (11/18) Oct 28 2006 It still doesn't work in GDC, though:
- Kyle Furlong (2/37) Oct 27 2006 You should look at Ares + Mango. IO is very well implemented.
- Sean Kelly (10/47) Oct 27 2006 This is largely a result of the naming convention evolving over time,
- Chad J (7/50) Oct 27 2006 uh, too true.
I'm new to D so please forgive my ignorance if indeed that's what it is.
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
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
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
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
Frits van Bommel <fvbommel REMwOVExCAPSs.nl> Wolfgang Draxinger wrote:Frits van Bommel wrote: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.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.
Oct 27 2006
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
Anders F Björklund wrote:Frits van Bommel wrote:Yeah, that too :).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 :-)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
Frits van Bommel wrote:Anders F Björklund wrote: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).Frits van Bommel wrote:Yeah, that too :).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 :-)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
"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).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
Jarrett Billingsley wrote:[...]how aboutdin.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
Chad J wrote:Frits van Bommel wrote:You should look at Ares + Mango. IO is very well implemented.Anders F Björklund wrote: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).Frits van Bommel wrote:Yeah, that too :).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 :-)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
Brian Hay wrote:I'm new to D so please forgive my ignorance if indeed that's what it is. 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
Brian Hay wrote:
I'm new to D so please forgive my ignorance if indeed that's what it is.
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