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.

 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

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.

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

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

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

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.

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? ;)

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.

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().