## digitalmars.D - string vs String

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!!

--


Dec 13 2007
"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).

Dec 13 2007
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)

Dec 14 2007
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

Dec 14 2007
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 ...

Dec 14 2007
"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

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

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

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.

Dec 14 2007
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).

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)

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

Dec 14 2007
"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.

Dec 14 2007
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.

Dec 14 2007
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

Dec 14 2007
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.

Dec 14 2007