• davidl (6/6) Dec 13 2007 I noticed object.d alias string as invariant(char)[]
• Janice Caron (11/15) Dec 13 2007 So ... change your app?
• Colin Huang (3/9) Dec 14 2007 Agreed :)
• Bill Baxter (6/18) Dec 14 2007 Tango names _Packages_ with with capitalized words, but not the modules....
• Colin Huang (5/25) Dec 14 2007 Perhaps I'm misunderstanding here, but have a look at the following code
• Simen Kjaeraas (4/35) Dec 14 2007 Seems Bill was just mixing things up. From a quick look at my Tango
• Bill Baxter (6/33) Dec 14 2007 Doh! I got it backwards. Sorry. Anyway the modules and packages have
• Bruce Adams (10/27) Dec 14 2007 Actually if D had namespaces he wouldn't need to be clairvoyant. Everyth...
• Pedro Ferreira (5/38) Dec 14 2007 If you want namespaces, do
• Derek Parnell (8/13) Dec 14 2007 This suggestion is a little late I guess, but I try to never have my own
• Christopher Wright (2/9) Dec 14 2007 Primitives get lower-case identifiers. That's all there is to it.

davidl <davidl 126.com> writes:

I noticed object.d alias string as invariant(char)[]

But it's a bad choice of the name. string causes a lot name collision in  
my app.
And as a type. with first char capitalized is a much better choice!!

-- 
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/

"Janice Caron" <caron800 googlemail.com> writes:

On 12/14/07, davidl <davidl 126.com> wrote:
 I noticed object.d alias string as invariant(char)[]

 But it's a bad choice of the name. string causes a lot name collision in
 my app.

So ... change your app?

Seriously, there's no way Walter could possibly have known what name
choices you had made in your app, unless you're suggesting that Walter
should be more clairvoyant.

 And as a type. with first char capitalized is a much better choice!!

And do you suppose that this would cause no name clashes at all with
anyone's apps? I imagine it would cause /more/. Anyone who's ever made
a string class has probably called it "String". To me, the lower case
s not only ensures fewer name clashes, but also makes it "feel" like a
primitive type (which it sort of almost is - I mean it's just an
array, not actually a class or a struct).

Colin Huang <colin.hwong gmail.com> writes:

Janice Caron Wrote:

 And do you suppose that this would cause no name clashes at all with
 anyone's apps? I imagine it would cause /more/. Anyone who's ever made
 a string class has probably called it "String". To me, the lower case
 s not only ensures fewer name clashes, but also makes it "feel" like a
 primitive type (which it sort of almost is - I mean it's just an
 array, not actually a class or a struct).

Agreed :)

On an unrelated note, module names starting with uppercase letters (like those
in Tango) have always turned me off -- feels too Java-ish to me :P (I remember
reading somewhere in the forum that this is done for good reasons, though)

Bill Baxter <dnewsgroup billbaxter.com> writes:

Colin Huang wrote:
 Janice Caron Wrote:
 
 And do you suppose that this would cause no name clashes at all with
 anyone's apps? I imagine it would cause /more/. Anyone who's ever made
 a string class has probably called it "String". To me, the lower case
 s not only ensures fewer name clashes, but also makes it "feel" like a
 primitive type (which it sort of almost is - I mean it's just an
 array, not actually a class or a struct).

 
 Agreed :)
 
 On an unrelated note, module names starting with uppercase letters (like those
in Tango) have always turned me off -- feels too Java-ish to me :P (I remember
reading somewhere in the forum that this is done for good reasons, though)

Tango names _Packages_ with with capitalized words, but not the modules. 
  This allows you to have a module that's the same name as a package. 
Like "String.string".  "String" is a package/directory and "string.d" is 
a file in that directory.

--bb

Colin Huang <colin.hwong gmail.com> writes:

Bill Baxter Wrote:

 Colin Huang wrote:
 Janice Caron Wrote:
 
 And do you suppose that this would cause no name clashes at all with
 anyone's apps? I imagine it would cause /more/. Anyone who's ever made
 a string class has probably called it "String". To me, the lower case
 s not only ensures fewer name clashes, but also makes it "feel" like a
 primitive type (which it sort of almost is - I mean it's just an
 array, not actually a class or a struct).

 
 Agreed :)
 
 On an unrelated note, module names starting with uppercase letters (like those
in Tango) have always turned me off -- feels too Java-ish to me :P (I remember
reading somewhere in the forum that this is done for good reasons, though)

 
 Tango names _Packages_ with with capitalized words, but not the modules. 
   This allows you to have a module that's the same name as a package. 
 Like "String.string".  "String" is a package/directory and "string.d" is 
 a file in that directory.
 
 --bb

Perhaps I'm misunderstanding here, but have a look at the following code
from tango-bin-win32-CURRENT-dmd.1.022 (in file \import\tango\text\String.d):

module tango.text.String;

Isn't this a module with a capitalized name? I'm confused ...

"Simen Kjaeraas" <simen.kjaras gmail.com> writes:

On Fri, 14 Dec 2007 10:14:40 +0100, Colin Huang <colin.hwong gmail.com>  
wrote:

 Bill Baxter Wrote:

 Colin Huang wrote:
 Janice Caron Wrote:

 And do you suppose that this would cause no name clashes at all with
 anyone's apps? I imagine it would cause /more/. Anyone who's ever  


 made
 a string class has probably called it "String". To me, the lower case
 s not only ensures fewer name clashes, but also makes it "feel" like  


 a
 primitive type (which it sort of almost is - I mean it's just an
 array, not actually a class or a struct).

 Agreed :)

 On an unrelated note, module names starting with uppercase letters  

 (like those in Tango) have always turned me off -- feels too Java-ish  
 to me :P (I remember reading somewhere in the forum that this is done  
 for good reasons, though)

 Tango names _Packages_ with with capitalized words, but not the modules.
   This allows you to have a module that's the same name as a package.
 Like "String.string".  "String" is a package/directory and "string.d" is
 a file in that directory.

 --bb

 Perhaps I'm misunderstanding here, but have a look at the following code
 from tango-bin-win32-CURRENT-dmd.1.022 (in file  
 \import\tango\text\String.d):

 module tango.text.String;

 Isn't this a module with a capitalized name? I'm confused ...

Seems Bill was just mixing things up. From a quick look at my Tango  
installation, it seems packages are lowercase, modules are capitalized.

Bill Baxter <dnewsgroup billbaxter.com> writes:

Colin Huang wrote:
 Bill Baxter Wrote:
 
 Colin Huang wrote:
 Janice Caron Wrote:

 And do you suppose that this would cause no name clashes at all with
 anyone's apps? I imagine it would cause /more/. Anyone who's ever made
 a string class has probably called it "String". To me, the lower case
 s not only ensures fewer name clashes, but also makes it "feel" like a
 primitive type (which it sort of almost is - I mean it's just an
 array, not actually a class or a struct).

 Agreed :)

 On an unrelated note, module names starting with uppercase letters (like those
in Tango) have always turned me off -- feels too Java-ish to me :P (I remember
reading somewhere in the forum that this is done for good reasons, though)

 Tango names _Packages_ with with capitalized words, but not the modules. 
   This allows you to have a module that's the same name as a package. 
 Like "String.string".  "String" is a package/directory and "string.d" is 
 a file in that directory.

 --bb

 
 Perhaps I'm misunderstanding here, but have a look at the following code
 from tango-bin-win32-CURRENT-dmd.1.022 (in file \import\tango\text\String.d):
 
 module tango.text.String;
 
 Isn't this a module with a capitalized name? I'm confused ...

Doh!  I got it backwards.  Sorry.  Anyway the modules and packages have 
different capitalization so that a module and package can have the same 
name.

--bb

--bb

"Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:

On Fri, 14 Dec 2007 07:18:43 -0000, Janice Caron <caron800 googlemail.com>  
wrote:

 On 12/14/07, davidl <davidl 126.com> wrote:
 I noticed object.d alias string as invariant(char)[]

 But it's a bad choice of the name. string causes a lot name collision in
 my app.

 So ... change your app?

 Seriously, there's no way Walter could possibly have known what name
 choices you had made in your app, unless you're suggesting that Walter
 should be more clairvoyant.

 And as a type. with first char capitalized is a much better choice!!

 And do you suppose that this would cause no name clashes at all with
 anyone's apps? I imagine it would cause /more/. Anyone who's ever made
 a string class has probably called it "String". To me, the lower case
 s not only ensures fewer name clashes, but also makes it "feel" like a
 primitive type (which it sort of almost is - I mean it's just an
 array, not actually a class or a struct).

Actually if D had namespaces he wouldn't need to be clairvoyant. Everything
would be safely tucked away in namespace std:: and only imported if the  
programmer
asked. IIRC the argument against them was simplicity but them to me to be  
an
essential grouping structure at the architecture level. Of course the need  
for them
can be delayed a fair while in the land of modules.

Pedro Ferreira <asa.sad sadf.wa> writes:

Bruce Adams Wrote:

 On Fri, 14 Dec 2007 07:18:43 -0000, Janice Caron <caron800 googlemail.com>  
 wrote:
 
 On 12/14/07, davidl <davidl 126.com> wrote:
 I noticed object.d alias string as invariant(char)[]

 But it's a bad choice of the name. string causes a lot name collision in
 my app.

 So ... change your app?

 Seriously, there's no way Walter could possibly have known what name
 choices you had made in your app, unless you're suggesting that Walter
 should be more clairvoyant.

 And as a type. with first char capitalized is a much better choice!!

 And do you suppose that this would cause no name clashes at all with
 anyone's apps? I imagine it would cause /more/. Anyone who's ever made
 a string class has probably called it "String". To me, the lower case
 s not only ensures fewer name clashes, but also makes it "feel" like a
 primitive type (which it sort of almost is - I mean it's just an
 array, not actually a class or a struct).

 
 Actually if D had namespaces he wouldn't need to be clairvoyant. Everything
 would be safely tucked away in namespace std:: and only imported if the  
 programmer
 asked. IIRC the argument against them was simplicity but them to me to be  
 an
 essential grouping structure at the architecture level. Of course the need  
 for them
 can be delayed a fair while in the land of modules.

If you want namespaces, do

"static import" and you'll have to fully qualify the module identifier.
I'm not sure however if static "import object" works.

Anyway, if the OP wants to rename the standard "string" to "String" simply do
something like "import object : string=String" or something similar.

Derek Parnell <derek psych.ward> writes:

On Fri, 14 Dec 2007 15:09:22 +0800, davidl wrote:

 I noticed object.d alias string as invariant(char)[]
 
 But it's a bad choice of the name. string causes a lot name collision in  
 my app.
 And as a type. with first char capitalized is a much better choice!!

This suggestion is a little late I guess, but I try to never have my own
identifiers be either valid English words or be in a single case, just so I
can avoid things like 'string' popping up in D.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Christopher Wright <dhasenan gmail.com> writes:

davidl wrote:
 
 I noticed object.d alias string as invariant(char)[]
 
 But it's a bad choice of the name. string causes a lot name collision in 
 my app.
 And as a type. with first char capitalized is a much better choice!!
 

Primitives get lower-case identifiers. That's all there is to it.