digitalmars.D - should std package be renamed?

It seems ugly to me to have modules like std.stdio, std.stdarg, std.stdint 
and all the std.c.stdio, std.c.stdlib and friends. Anyone else think 
something should be done? The most obvious choice is to change "std" to "d" 
and move "std.c.foo" to "c.foo". For example the directory structure would 
become (where indenting indicates nesting)
phobos
  etc (same as before)
  c
    stdio
    stdlib
    stdarg
    ...
  d
    boxer
    conv
    ctype
    date
    ...
    stdarg
    stdio
    string
    ...
    zlib

For example instead of
  import std.stdio;
  import std.c.stdio;
  import std.string;
you'd write
  import d.stdio;
  import c.stdio;
  import d.string;

May 31 2005

Derek Parnell <derek psych.ward> writes:

On Tue, 31 May 2005 21:04:24 -0400, Ben Hinkle wrote:

 It seems ugly to me to have modules like std.stdio, std.stdarg, std.stdint 
 and all the std.c.stdio, std.c.stdlib and friends. Anyone else think 
 something should be done? The most obvious choice is to change "std" to "d" 
 and move "std.c.foo" to "c.foo". For example the directory structure would 
 become (where indenting indicates nesting)
 phobos
   etc (same as before)
   c
     stdio
     stdlib
     stdarg
     ...
   d
     boxer
     conv
     ctype
     date
     ...
     stdarg
     stdio
     string
     ...
     zlib
 
 For example instead of
   import std.stdio;
   import std.c.stdio;
   import std.string;
 you'd write
   import d.stdio;
   import c.stdio;
   import d.string;


Seems too sensible ... it'll never fly ;-)

Actually, I like the idea. It looks good and clearly understandable. 

I won't mind updating my existing source code for this change. However it
would help if we had a built-in compiler version identifier.

  d_version(0,126)
     import d.stdio;
  else
     import std.stdio;

  

-- 
Derek
Melbourne, Australia
1/06/2005 11:41:50 AM

May 31 2005

zwang <nehzgnaw gmail.com> writes:

I like the idea, though it would break all the existing code.

Ben Hinkle wrote:
 It seems ugly to me to have modules like std.stdio, std.stdarg, std.stdint 
 and all the std.c.stdio, std.c.stdlib and friends. Anyone else think 
 something should be done? The most obvious choice is to change "std" to "d" 
 and move "std.c.foo" to "c.foo". For example the directory structure would 
 become (where indenting indicates nesting)
 phobos
   etc (same as before)
   c
     stdio
     stdlib
     stdarg
     ...
   d
     boxer
     conv
     ctype
     date
     ...
     stdarg
     stdio
     string
     ...
     zlib
 
 For example instead of
   import std.stdio;
   import std.c.stdio;
   import std.string;
 you'd write
   import d.stdio;
   import c.stdio;
   import d.string;

May 31 2005

J C Calvarese<technocrat7 gmail.com> writes:

In article <d7j1ir$82d$1 digitaldaemon.com>, Ben Hinkle says...
It seems ugly to me to have modules like std.stdio, std.stdarg, std.stdint 
and all the std.c.stdio, std.c.stdlib and friends. Anyone else think 


I'd try renaming 
std.stdio > std.io 
std.stdarg > std.arg
std.stdint > std.integer
for starters.

something should be done? The most obvious choice is to change "std" to "d" 
and move "std.c.foo" to "c.foo". For example the directory structure would 
become (where indenting indicates nesting)
phobos
  etc (same as before)
  c
    stdio
    stdlib
    stdarg
    ...
  d
    boxer
    conv
    ctype
    date
    ...
    stdarg
    stdio
    string
    ...
    zlib

For example instead of
  import std.stdio;
  import std.c.stdio;
  import std.string;
you'd write
  import d.stdio;
  import c.stdio;
  import d.string;


I suggested a similar idea a couple years ago (before we had "std"), but it
turned out I was wrong. 

Walter's message from 17 Oct 2003:

"What happened was that I'd prefer just 'd', but it wound up causing problems
because 'd' was commonly used as a local variable name. 'D' is rarely used,
so seemed to make better sense.

"Compromises everywhere, sigh <g>."

(D/18378)


We managed to convince him that "D" wasn't good enough either and finally Walter
selected "std" as the name. I think Phobos could use some reorganization, but I
don't think "d" is the answer.

jcc7

May 31 2005

"Ben Hinkle" <ben.hinkle gmail.com> writes:

 I suggested a similar idea a couple years ago (before we had "std"), but 
 it
 turned out I was wrong.


Yeah I had a feeling it was proposed back when the Great Rename happened but 
I was too lazy to check the archives :-(

 Walter's message from 17 Oct 2003:

 "What happened was that I'd prefer just 'd', but it wound up causing 
 problems
 because 'd' was commonly used as a local variable name. 'D' is rarely 
 used,
 so seemed to make better sense.

 "Compromises everywhere, sigh <g>."

 (D/18378)


It's true that the code

  import d.string;
  int main() {
    int d = 10;
    char[] s = d.string.toString(d);
  }

would need to be written as either

  import d.string;
  int main() {
    int d = 10;
    char[] s = toString(d);
  }

or

  import d.string;
  int main() {
    int d = 10;
    char[] s = .d.string.toString(d);
  }

but to me that's ok. I wouldn't think "d" or "c" would be common top-level 
names. Importing in non-top-level scopes is unusual and not recommended IIRC 
so really the only conflict would be for top-level names.

 We managed to convince him that "D" wasn't good enough either and finally 
 Walter
 selected "std" as the name. I think Phobos could use some reorganization, 
 but I
 don't think "d" is the answer.

 jcc7

May 31 2005

Trevor Parscal <trevorparscal hotmail.com> writes:

Walter's message from 17 Oct 2003:

"What happened was that I'd prefer just 'd', but it wound up causing 
problems
because 'd' was commonly used as a local variable name. 'D' is rarely 
used,




Who names a variable d? That is the most non-descriptive variable name 
ever, and anyone who uses it should be slapped with a fine, payable to 
Walter's pay pal account.

x, y.. z.. I can see.. Like in coordinate systems.. I suppose I can 
event see w and h if you are so lazy you cant write width and height.. 
Which btw drives me insane... If d is a common variable name, local, 
global.. class members.. ANYTHING.. Than what are you using it for? 
PLEASE tell me!

And if nobody comes up with a good enough answer, we should punish the 
offenders by changing the library names and forcing them to write more 
descriptive names or their code will be broken.. (kinda joking here)

I am torn..
A: I think that it makes sense to have any standard libs should be in 
d.*, and c bindings should be in c.* and when we get to the point where 
we can bind another language's compiled crap, if ever, not that we need 
it, you could have cpp.* or something...

B: But you know, who cares what the names of the standard libs are. I 
admit, I cared at one point, but now I care about my own software. To 
tell you the truth, I don't use that much of the standard libs anyways, 
mostly just string stuff, which is all really well done anyways.

State your position...

A. Should we focus on writing new features, instead of changing existing 
code?

B. Is it important to focus on changing things before there is too much 
code it will break out there?

C. Do we all just rant cause we lack an outlet for this crap anywhere 
else.. (I mean, honestly, I can't talk to my fiance or my friends about 
this crap..)

Let the newsgroup know...

-- 
Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal hotmail.com

May 31 2005

"Andrew Fedoniouk" <news terrainformatica.com> writes:

d is distance, discriminant, data.


"Trevor Parscal" <trevorparscal hotmail.com> wrote in message 
news:d7jkm3$ofc$1 digitaldaemon.com...
Walter's message from 17 Oct 2003:

"What happened was that I'd prefer just 'd', but it wound up causing 
problems
because 'd' was commonly used as a local variable name. 'D' is rarely 
used,




 Who names a variable d? That is the most non-descriptive variable name 
 ever, and anyone who uses it should be slapped with a fine, payable to 
 Walter's pay pal account.

 x, y.. z.. I can see.. Like in coordinate systems.. I suppose I can event 
 see w and h if you are so lazy you cant write width and height.. Which btw 
 drives me insane... If d is a common variable name, local, global.. class 
 members.. ANYTHING.. Than what are you using it for? PLEASE tell me!

 And if nobody comes up with a good enough answer, we should punish the 
 offenders by changing the library names and forcing them to write more 
 descriptive names or their code will be broken.. (kinda joking here)

 I am torn..
 A: I think that it makes sense to have any standard libs should be in d.*, 
 and c bindings should be in c.* and when we get to the point where we can 
 bind another language's compiled crap, if ever, not that we need it, you 
 could have cpp.* or something...

 B: But you know, who cares what the names of the standard libs are. I 
 admit, I cared at one point, but now I care about my own software. To tell 
 you the truth, I don't use that much of the standard libs anyways, mostly 
 just string stuff, which is all really well done anyways.

 State your position...

 A. Should we focus on writing new features, instead of changing existing 
 code?

 B. Is it important to focus on changing things before there is too much 
 code it will break out there?

 C. Do we all just rant cause we lack an outlet for this crap anywhere 
 else.. (I mean, honestly, I can't talk to my fiance or my friends about 
 this crap..)

 Let the newsgroup know...

 -- 
 Thanks,
 Trevor Parscal
 www.trevorparscal.com
 trevorparscal hotmail.com

May 31 2005

Trevor Parscal <trevorparscal hotmail.com> writes:

Andrew Fedoniouk wrote:
 d is distance, discriminant, data.
 


If I were reading your code, how the hell would I know which one of 
those d was supposed to mean...

Programing is allot about choosing names for things... I am sure 
everyone using D has a sufficient vocab, probably better than mine. USE IT!

-- 
Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal hotmail.com

May 31 2005

"Andrew Fedoniouk" <news terrainformatica.com> writes:

"Trevor Parscal" <trevorparscal hotmail.com> wrote in message 
news:d7jl48$omj$1 digitaldaemon.com...
 Andrew Fedoniouk wrote:
 d is distance, discriminant, data.


 If I were reading your code, how the hell would I know which one of those 
 d was supposed to mean...


Easy, see:

bool HaveSpacesuitWillTravel()
{
  foreach(distance d; stars)
 {
    if (d <= 4.3)
       writef("Alpha Centaurus? Piece of cake!");
    else
      writef("Do you have a spare ion drive, BTW?");
  }
}

 Programing is allot about choosing names for things... I am sure everyone 
 using D has a sufficient vocab, probably better than mine. USE IT!

 -- 
 Thanks,
 Trevor Parscal
 www.trevorparscal.com
 trevorparscal hotmail.com

Jun 01 2005

Derek Parnell <derek psych.ward> writes:

On Tue, 31 May 2005 23:35:26 -0700, Andrew Fedoniouk wrote:

 d is distance, discriminant, data.


d is dumb  ;-)

-- 
Derek Parnell
Melbourne, Australia
1/06/2005 5:17:31 PM

Jun 01 2005

J C Calvarese<technocrat7 gmail.com> writes:

In article <1o6qpoefvv20w$.i85textgh7d9$.dlg 40tude.net>, Derek Parnell says...
On Tue, 31 May 2005 23:35:26 -0700, Andrew Fedoniouk wrote:

 d is distance, discriminant, data.


d is dumb  ;-)


It's not dumb. It's just the letter I use when a, b, and c are already used. :)

jcc7

Jun 01 2005

Trevor Parscal <Trevor_member pathlink.com> writes:

In article <d7jp8f$u1o$1 digitaldaemon.com>, J C Calvarese says...
In article <1o6qpoefvv20w$.i85textgh7d9$.dlg 40tude.net>, Derek Parnell says...
On Tue, 31 May 2005 23:35:26 -0700, Andrew Fedoniouk wrote:

 d is distance, discriminant, data.


d is dumb  ;-)


It's not dumb. It's just the letter I use when a, b, and c are already used. :)

jcc7


why use a, b, c, d... ? Arrays are SOOO much more flexible, powerful,
manageable, and in most cases, faster when compiled.

Eh.. whatever, It's not the point.. I won't name my varaible that way..

and why would you have a user data type that's all lowercase?

foreach(distance d; ...

Wouldnt that be

foreach(DISTANCE distance; ...

or 

foreach(Distance distance; ...

Well... I appricate the feedback anyhoo.

Have a good night gents!

Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal hotmail.com

Jun 01 2005

"Andrew Fedoniouk" <news terrainformatica.com> writes:

"Trevor Parscal" <Trevor_member pathlink.com> wrote in message 
news:d7jpo4$uad$1 digitaldaemon.com...
 In article <d7jp8f$u1o$1 digitaldaemon.com>, J C Calvarese says...
In article <1o6qpoefvv20w$.i85textgh7d9$.dlg 40tude.net>, Derek Parnell 
says...
On Tue, 31 May 2005 23:35:26 -0700, Andrew Fedoniouk wrote:

 d is distance, discriminant, data.


d is dumb  ;-)


It's not dumb. It's just the letter I use when a, b, and c are already 
used. :)

jcc7


 why use a, b, c, d... ? Arrays are SOOO much more flexible, powerful,
 manageable, and in most cases, faster when compiled.

 Eh.. whatever, It's not the point.. I won't name my varaible that way..

 and why would you have a user data type that's all lowercase?

 foreach(distance d; ...

 Wouldnt that be

 foreach(DISTANCE distance; ...

 or

 foreach(Distance distance; ...

 Well... I appricate the feedback anyhoo.


Naming is personal.

I am trying to use:
DISTANCE  - enum and its value, constants, template typenames.
Distance -  class and structure with semantic of class.
distance - aliased or typedefed ints, doubles, etc. and
                structures with semantic of value:
                e.g. rect, point, size - they are just basic values
                treated, as a rule, as one single entity.

Jun 02 2005

=?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:

Derek Parnell wrote:

d is distance, discriminant, data.


 d is dumb  ;-)


You are right, I will just name it ξ instead.
(just like a Math professor I once had did...)

--anders

Jun 01 2005

Trevor Parscal <trevorparscal hotmail.com> writes:

 d is dumb  ;-)




ownedah...

So what about my question? What should the focus be.. I suppose we all 
know it should be on progression, with a good balance of quality control 
and minor modification where needed, so nobody thought to answer...

Well, tomorrow morning (when I go to bed) I will be posting the latest 
and greatest of Terra (www.dsource.org/projects/terra) which means I 
have about 6 hours to get some serious crap working.. so, for tonight, 
the libraries should stay how they are so I can get something done 
instead of worrying about the name of std.stdio, as stupid as we all 
know that name is...

Program away mates.

-- 
Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal hotmail.com

Jun 01 2005

"Unknown W. Brackets" <unknown simplemachines.org> writes:

The variable "d" is often used in conjunction with "a", "b", and "c". 
For example, an implementation of the SHA-1 algorithm uses the first 
five letters of the alphabet in its formula.

I would hate to use a language that gave me an error like this:

test.d(10): the variable name "ab" is too short.

I hope you realize I would go to another compiler if I ever saw a 
message like that.  When writing programs for others to use, remember:

You and your program *are not* and *should not be portrayed as* better 
than the user, ever or even to any degree.  *The user is king*, and your 
program is his or her *LOWLY SERVANT*.

Anything else is offensive and annoying.

-[Unknown]


 Who names a variable d? That is the most non-descriptive variable name 
 ever, and anyone who uses it should be slapped with a fine, payable to 
 Walter's pay pal account.
 
 x, y.. z.. I can see.. Like in coordinate systems.. I suppose I can 
 event see w and h if you are so lazy you cant write width and height.. 
 Which btw drives me insane... If d is a common variable name, local, 
 global.. class members.. ANYTHING.. Than what are you using it for? 
 PLEASE tell me!

Jun 01 2005

J C Calvarese<technocrat7 gmail.com> writes:

In article <d7jkm3$ofc$1 digitaldaemon.com>, Trevor Parscal says...
Walter's message from 17 Oct 2003:

"What happened was that I'd prefer just 'd', but it wound up causing 
problems
because 'd' was commonly used as a local variable name. 'D' is rarely 
used,




Who names a variable d? That is the most non-descriptive variable name 
ever, and anyone who uses it should be slapped with a fine, payable to 
Walter's pay pal account.


Oh, come on now. I'd use "jeNeSaisQuoi", "savoirFaire", and "deJaVu" for
variable names instead, but they take a lot more effort to type.

..

C. Do we all just rant cause we lack an outlet for this crap anywhere 
else.. (I mean, honestly, I can't talk to my fiance or my friends about 
this crap..)


Probably.

jcc7

Jun 01 2005

zwang <nehzgnaw gmail.com> writes:

Trevor Parscal wrote:
 
 Walter's message from 17 Oct 2003:

 "What happened was that I'd prefer just 'd', but it wound up causing 
 problems
 because 'd' was commonly used as a local variable name. 'D' is rarely 
 used,




 
 Who names a variable d? That is the most non-descriptive variable name 
 ever, and anyone who uses it should be slapped with a fine, payable to 
 Walter's pay pal account.
 
 x, y.. z.. I can see.. Like in coordinate systems.. I suppose I can 
 event see w and h if you are so lazy you cant write width and height.. 
 Which btw drives me insane... If d is a common variable name, local, 
 global.. class members.. ANYTHING.. Than what are you using it for? 
 PLEASE tell me!
 --snip--


foreach(DiscriminatedIdentifier d; shortNames)
     unsegregate(d);

Jun 01 2005

"Ben Hinkle" <ben.hinkle gmail.com> writes:

"Trevor Parscal" <trevorparscal hotmail.com> wrote in message 
news:d7jkm3$ofc$1 digitaldaemon.com...
Walter's message from 17 Oct 2003:

"What happened was that I'd prefer just 'd', but it wound up causing 
problems
because 'd' was commonly used as a local variable name. 'D' is rarely 
used,




 Who names a variable d? That is the most non-descriptive variable name 
 ever, and anyone who uses it should be slapped with a fine, payable to 
 Walter's pay pal account.


I don't believe the fact that d and c can be variables should impact the 
package name. Full package.module names in code are very rare and in those 
cases .c.foo and .d.bar can be used just fine to access the toplevel 
package. In fact I will bet the most common use of full package name will be 
for calling toString in std.string inside a class definition and for that 
one already requires .std.string.toString to distinguish it from 
Object.toString.

[snip]
 B: But you know, who cares what the names of the standard libs are. I 
 admit, I cared at one point, but now I care about my own software. To tell 
 you the truth, I don't use that much of the standard libs anyways, mostly 
 just string stuff, which is all really well done anyways.


Are there things you'd like to use from the standard lib but aren't there?

 State your position...

 A. Should we focus on writing new features, instead of changing existing 
 code?


It shouldn't matter. Whatever makes D better.

 B. Is it important to focus on changing things before there is too much 
 code it will break out there?


Agreed. IMO D is so young breaking code is low on the priority list. Better 
to remove warts now than be in the position of C++ where the warts have 
grown so old they are unchangable. In any case I'd be shocked if a rote 
replacement of "std.c." to "c." and then "std." to "d." doesn't just do the 
trick for the vast majority of code.

Jun 01 2005

zwang <nehzgnaw gmail.com> writes:

Ben Hinkle wrote:
 <snip>
 Agreed. IMO D is so young breaking code is low on the priority list. Better 
 to remove warts now than be in the position of C++ where the warts have 
 grown so old they are unchangable. In any case I'd be shocked if a rote 
 replacement of "std.c." to "c." and then "std." to "d." doesn't just do the 
 trick for the vast majority of code. 
 
 


What's the biggest benefit of renaming std in the first place?
To make the code more visually appealing and succinct (by a few bytes)?

Personally I like your idea, but I think it's more appropriate to consider
the renaming scheme when the whole standard library is restructured.

Jun 01 2005

"Ben Hinkle" <ben.hinkle gmail.com> writes:

"zwang" <nehzgnaw gmail.com> wrote in message 
news:d7kb2q$1jch$1 digitaldaemon.com...
 Ben Hinkle wrote:
 <snip>
 Agreed. IMO D is so young breaking code is low on the priority list. 
 Better to remove warts now than be in the position of C++ where the warts 
 have grown so old they are unchangable. In any case I'd be shocked if a 
 rote replacement of "std.c." to "c." and then "std." to "d." doesn't just 
 do the trick for the vast majority of code.


 What's the biggest benefit of renaming std in the first place?
 To make the code more visually appealing and succinct (by a few bytes)?


Visually appealing. The names "std.stdio" "std.c.stdio" look silly. Renaming 
just the std.stdfoo modules would be ok, too, if a good set of names could 
be found. Keeping "stdio" as one word helps clue people into the fact that 
it's a simple wrapper around std.c.stdio. The same argument applies to 
stdlib and stdarg.

 Personally I like your idea, but I think it's more appropriate to consider
 the renaming scheme when the whole standard library is restructured.


Maybe - though I'm not holding my breath for that. Doing just the name 
change has the advantage of being easily automated. Updating code for a 
restructuring would presumably need more manual involvement.

Jun 01 2005

bobef <bobef_member pathlink.com> writes:

I use d and a and b and c and aa and bb and cc and a1 and a2 an so on... when i
need to get a temporary value and i am lazy to write any thing i just pres a
random character... 

In article <d7jkm3$ofc$1 digitaldaemon.com>, Trevor Parscal says...
Walter's message from 17 Oct 2003:

"What happened was that I'd prefer just 'd', but it wound up causing 
problems
because 'd' was commonly used as a local variable name. 'D' is rarely 
used,




Who names a variable d? That is the most non-descriptive variable name 
ever, and anyone who uses it should be slapped with a fine, payable to 
Walter's pay pal account.

x, y.. z.. I can see.. Like in coordinate systems.. I suppose I can 
event see w and h if you are so lazy you cant write width and height.. 
Which btw drives me insane... If d is a common variable name, local, 
global.. class members.. ANYTHING.. Than what are you using it for? 
PLEASE tell me!

And if nobody comes up with a good enough answer, we should punish the 
offenders by changing the library names and forcing them to write more 
descriptive names or their code will be broken.. (kinda joking here)

I am torn..
A: I think that it makes sense to have any standard libs should be in 
d.*, and c bindings should be in c.* and when we get to the point where 
we can bind another language's compiled crap, if ever, not that we need 
it, you could have cpp.* or something...

B: But you know, who cares what the names of the standard libs are. I 
admit, I cared at one point, but now I care about my own software. To 
tell you the truth, I don't use that much of the standard libs anyways, 
mostly just string stuff, which is all really well done anyways.

State your position...

A. Should we focus on writing new features, instead of changing existing 
code?

B. Is it important to focus on changing things before there is too much 
code it will break out there?

C. Do we all just rant cause we lack an outlet for this crap anywhere 
else.. (I mean, honestly, I can't talk to my fiance or my friends about 
this crap..)

Let the newsgroup know...

-- 
Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal hotmail.com

Jun 01 2005

Hasan Aljudy <hasan.aljudy gmail.com> writes:

J C Calvarese wrote:
 In article <d7j1ir$82d$1 digitaldaemon.com>, Ben Hinkle says...
 
It seems ugly to me to have modules like std.stdio, std.stdarg, std.stdint 
and all the std.c.stdio, std.c.stdlib and friends. Anyone else think 


 
 I'd try renaming 
 std.stdio > std.io 
 std.stdarg > std.arg
 std.stdint > std.integer
 for starters.


Makes perfect snese to me ...
Remove the redundancy, what the hell is the meaning of "stdio" inside 
"std"? just call it "io"!

 
 
something should be done? The most obvious choice is to change "std" to "d" 
and move "std.c.foo" to "c.foo". For example the directory structure would 
become (where indenting indicates nesting)
phobos
 etc (same as before)
 c
   stdio
   stdlib
   stdarg
   ...
 d
   boxer
   conv
   ctype
   date
   ...
   stdarg
   stdio
   string
   ...
   zlib

For example instead of
 import std.stdio;
 import std.c.stdio;
 import std.string;
you'd write
 import d.stdio;
 import c.stdio;
 import d.string;


 
 I suggested a similar idea a couple years ago (before we had "std"), but it
 turned out I was wrong. 
 
 Walter's message from 17 Oct 2003:
 
 "What happened was that I'd prefer just 'd', but it wound up causing problems
 because 'd' was commonly used as a local variable name. 'D' is rarely used,
 so seemed to make better sense.
 
 "Compromises everywhere, sigh <g>."
 
 (D/18378)
 
 
 We managed to convince him that "D" wasn't good enough either and finally
Walter
 selected "std" as the name. I think Phobos could use some reorganization, but I
 don't think "d" is the answer.
 
 jcc7


Ah, how sad, I kind of liked the idea :/

atleast
std.c.*
should be renamed to
cstd.*
or something like that.

May 31 2005

kris <fu bar.org> writes:

So I'll be an ass, and postulate "use mango.io instead?"

<g>


J C Calvarese wrote:
 In article <d7j1ir$82d$1 digitaldaemon.com>, Ben Hinkle says...
 
It seems ugly to me to have modules like std.stdio, std.stdarg, std.stdint 
and all the std.c.stdio, std.c.stdlib and friends. Anyone else think 


 
 I'd try renaming 
 std.stdio > std.io 
 std.stdarg > std.arg
 std.stdint > std.integer
 for starters.
 
 
something should be done? The most obvious choice is to change "std" to "d" 
and move "std.c.foo" to "c.foo". For example the directory structure would 
become (where indenting indicates nesting)
phobos
 etc (same as before)
 c
   stdio
   stdlib
   stdarg
   ...
 d
   boxer
   conv
   ctype
   date
   ...
   stdarg
   stdio
   string
   ...
   zlib

For example instead of
 import std.stdio;
 import std.c.stdio;
 import std.string;
you'd write
 import d.stdio;
 import c.stdio;
 import d.string;


 
 I suggested a similar idea a couple years ago (before we had "std"), but it
 turned out I was wrong. 
 
 Walter's message from 17 Oct 2003:
 
 "What happened was that I'd prefer just 'd', but it wound up causing problems
 because 'd' was commonly used as a local variable name. 'D' is rarely used,
 so seemed to make better sense.
 
 "Compromises everywhere, sigh <g>."
 
 (D/18378)
 
 
 We managed to convince him that "D" wasn't good enough either and finally
Walter
 selected "std" as the name. I think Phobos could use some reorganization, but I
 don't think "d" is the answer.
 
 jcc7

May 31 2005

"Andrew Fedoniouk" <news terrainformatica.com> writes:

"kris" <fu bar.org> wrote in message news:d7jjj4$nkc$1 digitaldaemon.com...
 So I'll be an ass, and postulate "use mango.io instead?"


Harmonia also got harmonia.io.
Nothing spectacular there though. GUI related io.

Andrew.





 <g>


 J C Calvarese wrote:
 In article <d7j1ir$82d$1 digitaldaemon.com>, Ben Hinkle says...

It seems ugly to me to have modules like std.stdio, std.stdarg, 
std.stdint and all the std.c.stdio, std.c.stdlib and friends. Anyone else 
think



 I'd try renaming std.stdio > std.io std.stdarg > std.arg
 std.stdint > std.integer
 for starters.


something should be done? The most obvious choice is to change "std" to 
"d" and move "std.c.foo" to "c.foo". For example the directory structure 
would become (where indenting indicates nesting)
phobos
 etc (same as before)
 c
   stdio
   stdlib
   stdarg
   ...
 d
   boxer
   conv
   ctype
   date
   ...
   stdarg
   stdio
   string
   ...
   zlib

For example instead of
 import std.stdio;
 import std.c.stdio;
 import std.string;
you'd write
 import d.stdio;
 import c.stdio;
 import d.string;



 I suggested a similar idea a couple years ago (before we had "std"), but 
 it
 turned out I was wrong. Walter's message from 17 Oct 2003:

 "What happened was that I'd prefer just 'd', but it wound up causing 
 problems
 because 'd' was commonly used as a local variable name. 'D' is rarely 
 used,
 so seemed to make better sense.

 "Compromises everywhere, sigh <g>."

 (D/18378)


 We managed to convince him that "D" wasn't good enough either and finally 
 Walter
 selected "std" as the name. I think Phobos could use some reorganization, 
 but I
 don't think "d" is the answer.

 jcc7

May 31 2005

kris <fu bar.org> writes:

Andrew Fedoniouk wrote:
 "kris" <fu bar.org> wrote in message news:d7jjj4$nkc$1 digitaldaemon.com...
 
So I'll be an ass, and postulate "use mango.io instead?"


 
 Harmonia also got harmonia.io.
 Nothing spectacular there though. GUI related io.
 
 Andrew.


Wasn't there some kind of tripped-out psychedelic folk-music act in the 
sixties called "Harmonia & Mango" ?

May 31 2005

"Andrew Fedoniouk" <news terrainformatica.com> writes:

"kris" <fu bar.org> wrote in message news:d7jllh$pad$1 digitaldaemon.com...
 Andrew Fedoniouk wrote:
 "kris" <fu bar.org> wrote in message 
 news:d7jjj4$nkc$1 digitaldaemon.com...

So I'll be an ass, and postulate "use mango.io instead?"



 Harmonia also got harmonia.io.
 Nothing spectacular there though. GUI related io.

 Andrew.


 Wasn't there some kind of tripped-out psychedelic folk-music act in the 
 sixties called "Harmonia & Mango" ?


:)

Jun 01 2005

J C Calvarese<technocrat7 gmail.com> writes:

In article <d7jjj4$nkc$1 digitaldaemon.com>, kris says...
So I'll be an ass, and postulate "use mango.io instead?"

<g>


Can we continue the tread, then...

std.stdarg > mango.arg
std.stdint > mango.integer

=)

J C Calvarese wrote:
 In article <d7j1ir$82d$1 digitaldaemon.com>, Ben Hinkle says...
 
It seems ugly to me to have modules like std.stdio, std.stdarg, std.stdint 
and all the std.c.stdio, std.c.stdlib and friends. Anyone else think 


 
 I'd try renaming 
 std.stdio > std.io 
 std.stdarg > std.arg
 std.stdint > std.integer
 for starters.




..

jcc7

Jun 01 2005

"Andrew Fedoniouk" <news terrainformatica.com> writes:

The best name for such package is 'foo'.
As nobody in good mood will name anything
by this name.

In each joke there is a portion of ... joke.

Andrew.


"Ben Hinkle" <ben.hinkle gmail.com> wrote in message 
news:d7j1ir$82d$1 digitaldaemon.com...
 It seems ugly to me to have modules like std.stdio, std.stdarg, std.stdint 
 and all the std.c.stdio, std.c.stdlib and friends. Anyone else think 
 something should be done? The most obvious choice is to change "std" to 
 "d" and move "std.c.foo" to "c.foo". For example the directory structure 
 would become (where indenting indicates nesting)
 phobos
  etc (same as before)
  c
    stdio
    stdlib
    stdarg
    ...
  d
    boxer
    conv
    ctype
    date
    ...
    stdarg
    stdio
    string
    ...
    zlib

 For example instead of
  import std.stdio;
  import std.c.stdio;
  import std.string;
 you'd write
  import d.stdio;
  import c.stdio;
  import d.string;

May 31 2005

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Ben Hinkle wrote:

 It seems ugly to me to have modules like std.stdio, std.stdarg, std.stdint 
 and all the std.c.stdio, std.c.stdlib and friends. Anyone else think 
 something should be done? The most obvious choice is to change "std" to "d" 
 and move "std.c.foo" to "c.foo".


But isn't "std" the Phobos namespace ? Meaning that moving "c" out of
it would split the namespace, and in a sense leave the Phobos domain ?

I guess "std.d.module" would be the "proper" name for the modules,
if it wasn't for the redundancy and the extra level of indirection...

And since the D library depends on the C library, do you really want to
separate them into two different dir trees ? (They're already a subdir)


Like other posters, I think it *was* previously called "d" but that it
wasn't a practical name for a top-level domain ? (neither would "c" be)

There was a long debate on whether it should be called "phobos" instead
of "std" (and "deimos" instead of "etc") - but Walter didn't think so.


As for renaming stdio, it could probably be done. If there's a reason ?
But rename stdin and stdout too then, to not use old C "FILE*" anymore.

"stdint.d" is just for C/C++ compatibility, so less need to rename ?
(stdarg is a D version, it could be renamed to "vararg". Or something)


But:
I'd much rather see adding the missing "i" to the stdio, or nuking the
appearance of "printf" in Object from orbit (the only way to make sure)

Or removing the "etc" dir from the DMD distribution, but that's a whole
other discussion topic and I'm in the minority there too - as usual ;-)

--anders

Jun 01 2005

"Ben Hinkle" <bhinkle mathworks.com> writes:

"Anders F Bj�rklund" <afb algonet.se> wrote in message 
news:d7jso2$11dj$1 digitaldaemon.com...
 Ben Hinkle wrote:

 It seems ugly to me to have modules like std.stdio, std.stdarg, 
 std.stdint and all the std.c.stdio, std.c.stdlib and friends. Anyone else 
 think something should be done? The most obvious choice is to change 
 "std" to "d" and move "std.c.foo" to "c.foo".


 But isn't "std" the Phobos namespace ? Meaning that moving "c" out of
 it would split the namespace, and in a sense leave the Phobos domain ?

 I guess "std.d.module" would be the "proper" name for the modules,
 if it wasn't for the redundancy and the extra level of indirection...

 And since the D library depends on the C library, do you really want to
 separate them into two different dir trees ? (They're already a subdir)


I think of "std" and "phobos" as different things. I'm sure you remember the 
recent thread about "what is phobos" and "what is the standard library" and 
"what is std" etc. I don't want to get into that again, though. The "std" 
package is just a mechanism to help prevent module clashes. It could be 
called "sys" or "bob" for all I care.

 Like other posters, I think it *was* previously called "d" but that it
 wasn't a practical name for a top-level domain ? (neither would "c" be)


Originally there wasn't any prefix. For example the thread module was 
"thread" and string was "string. Then D.win32 or something like that was 
added and the topic came up about prefixes. So "std" was the only uniform 
prefix phobos has ever had AFAIK.

 There was a long debate on whether it should be called "phobos" instead
 of "std" (and "deimos" instead of "etc") - but Walter didn't think so.


I don't like phobos as the package name either.

 As for renaming stdio, it could probably be done. If there's a reason ?
 But rename stdin and stdout too then, to not use old C "FILE*" anymore.


Which stdin and stdout are you referring to?

 "stdint.d" is just for C/C++ compatibility, so less need to rename ?
 (stdarg is a D version, it could be renamed to "vararg". Or something)


True. stdarg is the existing name for such a thing though so it has an 
advantage over vararg

 But:
 I'd much rather see adding the missing "i" to the stdio, or nuking the
 appearance of "printf" in Object from orbit (the only way to make sure)


What missing "i"?

 Or removing the "etc" dir from the DMD distribution, but that's a whole
 other discussion topic and I'm in the minority there too - as usual ;-)

 --anders

Jun 01 2005

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Ben Hinkle wrote:

As for renaming stdio, it could probably be done. If there's a reason ?
But rename stdin and stdout too then, to not use old C "FILE*" anymore.


 Which stdin and stdout are you referring to?


Well, if "std" is dropped from io - shouldn't it be from in and out too?

I'd much rather see adding the missing "i" to the stdio, or nuking the
appearance of "printf" in Object from orbit (the only way to make sure)


 What missing "i"?


Input... (readf)

--anders

Jun 01 2005

"Ben Hinkle" <ben.hinkle gmail.com> writes:

"Anders F Bj�rklund" <afb algonet.se> wrote in message 
news:d7kl75$1vjt$1 digitaldaemon.com...
 Ben Hinkle wrote:

As for renaming stdio, it could probably be done. If there's a reason ?
But rename stdin and stdout too then, to not use old C "FILE*" anymore.


 Which stdin and stdout are you referring to?


 Well, if "std" is dropped from io - shouldn't it be from in and out too?


I'm not suggesting stdio be dropped to d.io or std.io (though another post 
did suggest std.io). So I see no problem with keeping stdio as one word. 
Same goes for stdin stdout and stderr. The obvious downside of dropping the 
std from stdin and stdout is that in and out are keywords.

I'd much rather see adding the missing "i" to the stdio, or nuking the
appearance of "printf" in Object from orbit (the only way to make sure)


 What missing "i"?


 Input... (readf)


ok I understand you now. There are plenty of content changes that would be 
nice for phobos, I agree. A name change could actually be one of the 
simplest changes to make.

Jun 01 2005

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Ben Hinkle wrote:

Well, if "std" is dropped from io - shouldn't it be from in and out too?


 I'm not suggesting stdio be dropped to d.io or std.io (though another post 
 did suggest std.io). So I see no problem with keeping stdio as one word. 
 Same goes for stdin stdout and stderr. The obvious downside of dropping the 
 std from stdin and stdout is that in and out are keywords.


I think the OP had "din" and "dout", or something like that ?

Must say that I vastly prefer stdio, stdin and stdout myself.


But it would be nice if I could import both std.stdio and
std.stream, without them tripping all over eachother...

"variable std.c.stdio.stdout conflicts with std.stream.stdout"

--anders

Jun 01 2005

"Ben Hinkle" <bhinkle mathworks.com> writes:

"Anders F Bj�rklund" <afb algonet.se> wrote in message 
news:d7kp6u$23jr$1 digitaldaemon.com...
 Ben Hinkle wrote:

Well, if "std" is dropped from io - shouldn't it be from in and out too?


 I'm not suggesting stdio be dropped to d.io or std.io (though another 
 post did suggest std.io). So I see no problem with keeping stdio as one 
 word. Same goes for stdin stdout and stderr. The obvious downside of 
 dropping the std from stdin and stdout is that in and out are keywords.


 I think the OP had "din" and "dout", or something like that ?

 Must say that I vastly prefer stdio, stdin and stdout myself.


I think you are confusing this thread with another thread about the content 
of std.stdio and std.stream and the names of the stdin and friends. I also 
had a thread about renaming std.stdio to std.cstdio to reinforce the fact 
that std.stdio is a simple layer on top of std.stdio but I consider that 
thread to be different from this one, too..

 But it would be nice if I could import both std.stdio and
 std.stream, without them tripping all over eachother...

 "variable std.c.stdio.stdout conflicts with std.stream.stdout"


That's a different thread.

Jun 01 2005

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Ben Hinkle wrote:

 I think you are confusing this thread with another thread about the content 
 of std.stdio and std.stream and the names of the stdin and friends. I also 
 had a thread about renaming std.stdio to std.cstdio to reinforce the fact 
 that std.stdio is a simple layer on top of std.stdio but I consider that 
 thread to be different from this one, too..


That might very well be, I've had a most confusing day today :-)

But I guess I don't think "std" should be renamed to "d" either.

--anders

Jun 01 2005

"Kris" <fu bar.com> writes:

If you do this, Ben, then please add a "phobos." prefix to the entire
package. Phobos currently pollutes the top-level import namespace ~ rather
poor form, and hardly politically correct.

If, as you say, it's a simple mechanical upgrade, then should we not do this
instead?:

# import phobos.x.y;





"Ben Hinkle" <bhinkle mathworks.com> wrote in message
news:d7ki27$1s0l$1 digitaldaemon.com...
 "Anders F Bj�rklund" <afb algonet.se> wrote in message
 news:d7jso2$11dj$1 digitaldaemon.com...
 Ben Hinkle wrote:

 It seems ugly to me to have modules like std.stdio, std.stdarg,
 std.stdint and all the std.c.stdio, std.c.stdlib and friends. Anyone






 think something should be done? The most obvious choice is to change
 "std" to "d" and move "std.c.foo" to "c.foo".


 But isn't "std" the Phobos namespace ? Meaning that moving "c" out of
 it would split the namespace, and in a sense leave the Phobos domain ?

 I guess "std.d.module" would be the "proper" name for the modules,
 if it wasn't for the redundancy and the extra level of indirection...

 And since the D library depends on the C library, do you really want to
 separate them into two different dir trees ? (They're already a subdir)


 I think of "std" and "phobos" as different things. I'm sure you remember


 recent thread about "what is phobos" and "what is the standard library"


 "what is std" etc. I don't want to get into that again, though. The "std"
 package is just a mechanism to help prevent module clashes. It could be
 called "sys" or "bob" for all I care.

 Like other posters, I think it *was* previously called "d" but that it
 wasn't a practical name for a top-level domain ? (neither would "c" be)


 Originally there wasn't any prefix. For example the thread module was
 "thread" and string was "string. Then D.win32 or something like that was
 added and the topic came up about prefixes. So "std" was the only uniform
 prefix phobos has ever had AFAIK.

 There was a long debate on whether it should be called "phobos" instead
 of "std" (and "deimos" instead of "etc") - but Walter didn't think so.


 I don't like phobos as the package name either.

 As for renaming stdio, it could probably be done. If there's a reason ?
 But rename stdin and stdout too then, to not use old C "FILE*" anymore.


 Which stdin and stdout are you referring to?

 "stdint.d" is just for C/C++ compatibility, so less need to rename ?
 (stdarg is a D version, it could be renamed to "vararg". Or something)


 True. stdarg is the existing name for such a thing though so it has an
 advantage over vararg

 But:
 I'd much rather see adding the missing "i" to the stdio, or nuking the
 appearance of "printf" in Object from orbit (the only way to make sure)


 What missing "i"?

 Or removing the "etc" dir from the DMD distribution, but that's a whole
 other discussion topic and I'm in the minority there too - as usual ;-)

 --anders

Jun 01 2005

Trevor Parscal <trevorparscal hotmail.com> writes:

Kris wrote:
*snip*
 please add a "phobos." prefix to the entire
 package. Phobos currently pollutes the top-level import namespace ~ rather
 poor form, and hardly politically correct.
 
 If, as you say, it's a simple mechanical upgrade, then should we not do this
 instead?:
 
 # import phobos.x.y;
 


I vote for that. I think phobos, demios, mango, harmonia, whatever.. Its 
good they have creative names, stick with them, and use them to avoid 
polluting the namespace...

phobos.stdio; // seems allot less retarded..

demios
// now we know we are using demios, want documentation,
// look for demios documentation, not etc..

I for one run into this ALL the time. Type D into google.. You get 
nothing to do with D.. I have to type digital mars. Lets not do this to 
the standard library too, or any library.

My vote: Rename all packages to their "cute" names.

std -> phobos
etc -> demios

and keep that up from than on out.

-- 
Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal hotmail.com

Jun 01 2005

"Ben Hinkle" <ben.hinkle gmail.com> writes:

"Kris" <fu bar.com> wrote in message news:d7l6rl$2gv7$1 digitaldaemon.com...
 If you do this, Ben,


quick note: I'm not doing anything. Walter would do the changing. I'm just 
talking :-)

 then please add a "phobos." prefix to the entire
 package. Phobos currently pollutes the top-level import namespace ~ rather
 poor form, and hardly politically correct.


I'm not sure what you mean here by pollutes. How would phobos prefix be less 
polluting than std or d or anything else?

 If, as you say, it's a simple mechanical upgrade, then should we not do 
 this
 instead?:

 # import phobos.x.y;


The upgrade is mechanical but the phobos prefix has a couple downsides 
long-term IMHO: 1) not as pretty as std or d, 2) longer to type. We could 
mechanically change the prefix to foo (as suggested jokingly earlier) but 
that doesn't mean we should.

Jun 01 2005

Kramer <Kramer_member pathlink.com> writes:

I've always thought the std generally made sense, except in cases like
std.stdio.  Seems redundant.

-Kramer

In article <d7ldo3$2m81$1 digitaldaemon.com>, Ben Hinkle says...
"Kris" <fu bar.com> wrote in message news:d7l6rl$2gv7$1 digitaldaemon.com...
 If you do this, Ben,


quick note: I'm not doing anything. Walter would do the changing. I'm just 
talking :-)

 then please add a "phobos." prefix to the entire
 package. Phobos currently pollutes the top-level import namespace ~ rather
 poor form, and hardly politically correct.


I'm not sure what you mean here by pollutes. How would phobos prefix be less 
polluting than std or d or anything else?

 If, as you say, it's a simple mechanical upgrade, then should we not do 
 this
 instead?:

 # import phobos.x.y;


The upgrade is mechanical but the phobos prefix has a couple downsides 
long-term IMHO: 1) not as pretty as std or d, 2) longer to type. We could 
mechanically change the prefix to foo (as suggested jokingly earlier) but 
that doesn't mean we should.

Jun 01 2005

"Ben Hinkle" <ben.hinkle gmail.com> writes:

"Kramer" <Kramer_member pathlink.com> wrote in message 
news:d7lfl2$2nta$1 digitaldaemon.com...
 I've always thought the std generally made sense, except in cases like
 std.stdio.  Seems redundant.

 -Kramer


Agreed. std isn't so bad for std.string and some things like that. I happen 
to also think things like std.math and std.c.math would be better as d.math 
and c.math but definitely the double std modules are the least appealing.

Jun 01 2005

J C Calvarese<technocrat7 gmail.com> writes:

In article <d7lk1j$2r6f$1 digitaldaemon.com>, Ben Hinkle says...
"Kramer" <Kramer_member pathlink.com> wrote in message 
news:d7lfl2$2nta$1 digitaldaemon.com...
 I've always thought the std generally made sense, except in cases like
 std.stdio.  Seems redundant.

 -Kramer


Agreed. std isn't so bad for std.string and some things like that. I happen 
to also think things like std.math and std.c.math would be better as d.math 
and c.math but definitely the double std modules are the least appealing. 


Most of the double std modules could be easily fixed, by making a few
module-specific changes...

std.stdio  -> std.io
std.stdint -> std.integer
std.stdarg -> std.vararg

But I'm repeating myself, so I'll leave it there.

jcc7

Jun 01 2005

Trevor Parscal <trevorparscal hotmail.com> writes:

Are we still on this subject cause nothing has happened, or because the 
opposition to changing things feels the attack is not over?

Is D really done by committee? I thought we only had the power of 
suggestion. And to me, argument leads to only more fear of change (in 
Walter's eyes i suppose) as you don't want to anger the loyal 
programmers.. But also there is TechnoZeus (who I miss already) who, as 
someone already put it so very well, said "screw you guys, I'm going 
home" because the traditionalists, and those of us progressive minded 
people who can see eye to eye with them on this particular topic, didn't 
thing putting GUI code into phobos was a great idea...

Here it is. I love the D community, and I look forward to every day of 
programing and socializing over this newsgroup... But I have to ask 
myself, what is actually being done everyday. I mean, we should be 
talking about our projects, asking and answering questions, etc. Not 
arguing so very much.

So maybe Walter should have stuck with d instead of std. Lets just be 
content with whatever Walter decides for D, let him do what he WANTS to 
do, and not restrict him so much with out demands of traditionalism. 
Lets all work on a project of out own, or one on D source.

Anyone with me?

And yes, I like to type.. So sue me!

-- 
Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal hotmail.com

Jun 01 2005

Derek Parnell <derek psych.ward> writes:

On Wed, 01 Jun 2005 20:38:37 -0700, Trevor Parscal wrote:

 Are we still on this subject cause nothing has happened, 


Discussion itself is 'something happening'. Walter is never going to agree
to a change that will have a massive impact on the existing user base
unless there is some overwhelming reason to do so. So if we want this
changed we have to provide Walter with reasons that are so compelling that
to refuse the change would be stupid. I suspect that we have not achieved
that yet.

 or because the 
 opposition to changing things feels the attack is not over?


'attack'? What attack? By whom? Against whom? I do not believe that there
is a group of people on this list that opposes 'change' because it is
'change'. There always seems to be well thought through reasons for
opposition (even though I might not agree with them all the time).

 Is D really done by committee? I thought we only had the power of 
 suggestion. And to me, argument leads to only more fear of change (in 
 Walter's eyes i suppose) as you don't want to anger the loyal 
 programmers.. 


Huh? Excuse me for being blunt here, but that is plainly silly. You have no
evidence, and there is evidence to the contrary. Walter does not appear to
be fearful of change, if that change both improves D and helps D coders. In
the case of renaming the standard library packages, it is yet to be proven
that it either improves D or helps D coders. 

 But also there is TechnoZeus (who I miss already) who, as 
 someone already put it so very well, said "screw you guys, I'm going 
 home" because the traditionalists, and those of us progressive minded 
 people who can see eye to eye with them on this particular topic, didn't 
 thing putting GUI code into phobos was a great idea...


Firstly, he was requesting that GUI functionality be placed into the D
language itself; he was not asking for this to be placed into phobos.

Secondly, I'm not sure I understand what you are trying to say in the above
paragraph. It seems that you are saying that because "tradionalists" (who
ever they might be, and if they exist at all) didn't agree with
"progressive minded people", TechnoZeus couldn't handle the opposition
anymore and left. Well if that was true, that was his decision and what has
it got to do with the conduct of people of this list?

 Here it is. I love the D community, and I look forward to every day of 
 programing and socializing over this newsgroup... But I have to ask 
 myself, what is actually being done everyday. I mean, we should be 
 talking about our projects, asking and answering questions, etc. Not 
 arguing so very much.


Yes. If only D was stable, eh?

 So maybe Walter should have stuck with d instead of std. Lets just be 
 content with whatever Walter decides for D, let him do what he WANTS to 
 do, and not restrict him so much with out demands of traditionalism. 


Huh? What "demands of traditionalism"? Where are you getting this from?

We all have to accept that any idea that we put forward should be examined
by others and in doing so we may find out that it wasn't such a good idea
after all. Just because someone oppose one's idea, does not make that idea
good or bad; but we should listen anyway, so we can reexamine it ourselves
and adjust accordingly. Sometimes we might improve our idea, sometimes we
might discard it, and sometimes we just keep trying to prove its
'greatness'.

 Lets all work on a project of out own, or one on D source.
 
 Anyone with me?


I am working on one D Source project and will be starting another soon.
 
 And yes, I like to type.. So sue me!


Okay, so how about ...

  import module standard_input_output from package standard_d_phobos;

Relax ...  I'm just kidding ;-)

-- 
Derek
Melbourne, Australia
2/06/2005 2:55:29 PM

Jun 01 2005

J C Calvarese<technocrat7 gmail.com> writes:

In article <o45b1as34wwq.1l53owq6jbrgj.dlg 40tude.net>, Derek Parnell says...



 And yes, I like to type.. So sue me!


Okay, so how about ...

  import module standard_input_output from package standard_d_phobos;


LOL.

I think
"private import d_standard_library.standard_input_output;"
would be good enough.

jcc7

Jun 01 2005

Trevor Parscal <Trevor_member pathlink.com> writes:

I just wanted to say that althought I was being nice to TZ, I ABSOLUTELY agree
that he had a bad attitude, and ALSO that adding GUI code into the LANGUAGE is
not only retarded, but against the whole concept of a system level language.

I use D cause it's modern, system level, and fast. Not because it has "time
saving" gui features. Perhaps Visual Basic is the language he should go use.. I
started there, and thats perhaps why I can appricate having a real language to
write with at a system level...

Anyhoo, just wanted to say that I am glad that we can discuss this stuff, I
diddn't mean to dicousrage it.. Only to ask what people were thinking about the
reality of such changes.

I am glad this newsgroup isn't full of jerks like EFNet IRC rooms are... I can
ask a dumb question at 5:00am and not get ridiculed... To me, that is a good
comunity.

So yes, we should keep talking about this stuff, but mostly stick together and
stick with D.

I admit to having a fear that causes loss of sleep sometimes that D will die
like BeOS did, or that my software I write being open source will somehow screw
me over in the end... But something about this newsgroup helps me sleep.

So thanks for participating and reading the crap I write from time to time.

D = my language of choice, and I hope it to be for a very long time.

Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal hotmail.com

Jun 02 2005

John Reimer <brk_6502 yahoo.com> writes:

Trevor Parscal wrote:
 Are we still on this subject cause nothing has happened, or because the 
 opposition to changing things feels the attack is not over?
 
 Is D really done by committee? I thought we only had the power of 
 suggestion. And to me, argument leads to only more fear of change (in 
 Walter's eyes i suppose) as you don't want to anger the loyal 
 programmers.. But also there is TechnoZeus (who I miss already) who, as 
 someone already put it so very well, said "screw you guys, I'm going 
 home" because the traditionalists, and those of us progressive minded 
 people who can see eye to eye with them on this particular topic, didn't 
 thing putting GUI code into phobos was a great idea...
 
 Here it is. I love the D community, and I look forward to every day of 
 programing and socializing over this newsgroup... But I have to ask 
 myself, what is actually being done everyday. I mean, we should be 
 talking about our projects, asking and answering questions, etc. Not 
 arguing so very much.
 
 So maybe Walter should have stuck with d instead of std. Lets just be 
 content with whatever Walter decides for D, let him do what he WANTS to 
 do, and not restrict him so much with out demands of traditionalism. 
 Lets all work on a project of out own, or one on D source.
 
 Anyone with me?
 
 And yes, I like to type.. So sue me!
 


Oh, this sort of thing is nothing new. Just look over the last two years 
of postings, and you'll see.  If TechnoZeus indeed left, whatever...  He 
was opinionated, which is fine; but someone that opinionated shouldn't 
be discouraged if people don't listen to him or if they frankly disagree 
with his opinions.  It's give and take.  There have been several people 
that have left for the exact same reason as he, most quite 
knowledgable... and thin skinned.  Believe me, the ones that remain have 
their own battle scars to show if they were pushy about changes and some 
point.

It's the nature of the game on this newsgroup and no reason to 
disappear.  Thus, his leaving or staying isn't so critical to scheme of 
things as you might imagine. It's happened before; it'll happen again. 
Everyone's got to tough it out one way or another.  Those that do tend 
to have more influence in the long run.  Those that leave after only a 
couple months of flooding the newsgroup with ideas, won't get anywhere.

-JJR

Jun 01 2005

J C Calvarese<technocrat7 gmail.com> writes:

In article <d7luvv$2d8$1 digitaldaemon.com>, Trevor Parscal says...
Are we still on this subject cause nothing has happened, or because the 
opposition to changing things feels the attack is not over?


Sometimes, people just like to talk. I don't see a problem with that.

Is D really done by committee? 


Who said that it was. I think everyone involved in this discussion is quite
aware that Walter is the one who actually decides. But we can still rustle up
pro's and con's and offer suggestions and recommendation.

I thought we only had the power of 
suggestion. And to me, argument leads to only more fear of change (in 
Walter's eyes i suppose) as you don't want to anger the loyal 
programmers.. But also there is TechnoZeus (who I miss already) who, as 


If you compare the number of characters posted by TechnoZeus to the posts of his
"opponents", I think you'd find that TZ posted 5 times more content. We allowed
him to write what he wanted to write. Are we not allowed to disagree. Would you
prefer that no one ever replied to his posts or only post if you're going to
laud his ideas? I think people here generally disagreed with what he proposed
(yes, there were some exceptions). If D became what he envisioned, I'd likely
find another favorite language. And it was very hard to discuss anything with
him because to always seemed 100% convinced that he was absolutely right and we
were all utterly wrong. 

someone already put it so very well, said "screw you guys, I'm going 
home" because the traditionalists, and those of us progressive minded 
people who can see eye to eye with them on this particular topic, didn't 
thing putting GUI code into phobos was a great idea...


Actually, I wasn't even sure what he was proposing with the GUI concept, but
after his "implicit import" scheme, I was skeptical immediately. Every time
someone tried to restate his goal, he'd reply "No, that's not what I'm proposing
at all. Why must you lie about my idea?" Perhaps he's the kind of genius idea
that only someone with a 200+ IQ can comprehend. I don't know. If so, I guess
I'm not smart enough to comment.

Here it is. I love the D community, and I look forward to every day of 
programing and socializing over this newsgroup... But I have to ask 
myself, what is actually being done everyday. I mean, we should be 
talking about our projects, asking and answering questions, etc. Not 
arguing so very much.


If you don't like participating in the discussions, no one is making you
participate. These never-ending topics appear from time to time. Often, I ignore
them because I don't have anything meaningful (or new) to offer. (Sometimes, I
join the conversation even though I don't have anything meaningful to offer.) A
lot depends on my mood. I feel strongly about this topic, so I've made a few
posts. I might not post anymore about it since I think I've written what I want
to write. I don't really expect Walter to change "std" to "d" (which is fine
with me). I'm still hopeful he might change std.stdio to std.io (something I
first asked for months ago), but it won't be the end of the world if the status
quo remains.

So maybe Walter should have stuck with d instead of std. Lets just be 
content with whatever Walter decides for D, let him do what he WANTS to 
do, and not restrict him so much with out demands of traditionalism. 
Lets all work on a project of out own, or one on D source.


We know we can't demand anything of Walter (doesn't mean we won't try
sometimes). ;)

Anyone with me?


Partially.

And yes, I like to type.. So sue me!


You're not the only one who likes to type. Join the club.

jcc7

Jun 01 2005

"Ben Hinkle" <ben.hinkle gmail.com> writes:

"Trevor Parscal" <trevorparscal hotmail.com> wrote in message 
news:d7luvv$2d8$1 digitaldaemon.com...
 Are we still on this subject cause nothing has happened, or because the 
 opposition to changing things feels the attack is not over?


The battle is not over - send in the clones! :-)
Seriously, though, I think people said what they wanted to say and that's 
that. Walter can do what he wants.

 Is D really done by committee? I thought we only had the power of 
 suggestion. And to me, argument leads to only more fear of change (in 
 Walter's eyes i suppose) as you don't want to anger the loyal 
 programmers..


Interesting thoughts. I hope and suspect Walter isn't afraid to change 
things that have been around for a while. He's said the core parts of D are 
set so there are some things he won't change but I assumed before posting 
that the std name wasn't one of those things.

[snip]
 Here it is. I love the D community, and I look forward to every day of 
 programing and socializing over this newsgroup... But I have to ask 
 myself, what is actually being done everyday. I mean, we should be talking 
 about our projects, asking and answering questions, etc. Not arguing so 
 very much.


This newsgroup does tend to be the place where language topics come up that 
grow out of frustrations developed while working on a project. For example 
with me all the std.stdio and std.c.stdio typing that I've been doing to add 
FILE* streams lead me to remember how in the past some people complainded 
about std and so I thought I post and see what people thought. I don't think 
this thread was particularly argumentative - I tend to stop reading those 
that look like the posters have started arguing.

 So maybe Walter should have stuck with d instead of std. Lets just be 
 content with whatever Walter decides for D, let him do what he WANTS to 
 do, and not restrict him so much with out demands of traditionalism.


I don't understand what is meant by demands of traditionalism but aside from 
that I agree that Walter should do what he wants. The newsgroup is an 
important place for him to get feedback on D so I think the more posts about 
what's bothering people the better.

 Lets all work on a project of out own, or one on D source.

 Anyone with me?


I think one can work on projects and contribute to newsgroup discussions at 
the same time.

 And yes, I like to type.. So sue me!

 -- 
 Thanks,
 Trevor Parscal
 www.trevorparscal.com
 trevorparscal hotmail.com

Jun 02 2005

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

J C Calvarese wrote:

Agreed. std isn't so bad for std.string and some things like that. I happen 
to also think things like std.math and std.c.math would be better as d.math 
and c.math but definitely the double std modules are the least appealing. 


 Most of the double std modules could be easily fixed, by making a few
 module-specific changes...
 
 std.stdio  -> std.io
 std.stdint -> std.integer
 std.stdarg -> std.vararg
 
 But I'm repeating myself, so I'll leave it there.


Is *that* the problem here ? The two "std" ? :-O


But "stdint" is not just about any integer, it's about
porting from C/C++ ? Kinda like "stdbool", which is in
object.d (and inside the D compiler) at the moment...

http://www.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html
http://www.opengroup.org/onlinepubs/009695399/basedefs/stdbool.h.html
(but I won't bring my old stdutf and stdfloat suggestions up again...)

And what about the "std.c.windows.windows" or
"std.c.unix.unix". Are those also too repeated ?

(I don't see the problem with them, being used to:
#include <Carbon/Carbon.h> #import <Cocoa/Cocoa.h>)


Changing traditional stdio and stdarg just doesn't seem worth it, to me.
Besides, doesn't "io" already belong to *another* planet already ? ;-)

--anders

Jun 02 2005

"Kris" <fu bar.com> writes:

"Ben Hinkle" <ben.hinkle gmail.com> wrote in message
news:d7ldo3$2m81$1 digitaldaemon.com...
 "Kris" <fu bar.com> wrote in message


 If you do this, Ben,


 quick note: I'm not doing anything. Walter would do the changing. I'm just
 talking :-)

 then please add a "phobos." prefix to the entire
 package. Phobos currently pollutes the top-level import namespace ~




 poor form, and hardly politically correct.


 I'm not sure what you mean here by pollutes. How would phobos prefix be


 polluting than std or d or anything else?



Phobos currently has two root namespaces: std and etc. You're suggesting
adding another:
<quote>
The most obvious choice is to change "std" to "d" and move "std.c.foo" to
"c.foo".
</quote>

Do you think this would be the end of it? I don't. What if I already had a
root namespace called "d", or "c", or "io", or "math"? Such things have a
propensity to collide with packages designed and built independently. I
don't think it requires much imagination to see what a mess things could
become. There's good reason why other libraries have a single, unique root
name. Other than phobos, I don't know of another notable D library that is
not singly rooted.

Examine domain-names for some guidance on the subject?


 If, as you say, it's a simple mechanical upgrade, then should we not do
 this
 instead?:

 # import phobos.x.y;


 The upgrade is mechanical but the phobos prefix has a couple downsides
 long-term IMHO: 1) not as pretty as std or d, 2) longer to type. We could
 mechanically change the prefix to foo (as suggested jokingly earlier) but
 that doesn't mean we should.



1) Pretty?  :-D

I'll assume you're serious for the moment, and ask if we should change the
name of the library to something prettier also? How about "Tiffany", or
"BabyDoll", or "KoochyKoochyKooKode" ?

2) Takes longer to type.  Hmm. I can't imagine anyone wasting time on an
empirical study or some such, but the time it takes to type an import
statement must be rather low on the scale of time consumed by design,
development, debugging, and maintenance of the code itself.  I'd like to
quietly suggest that adding further robust development features to the
language (such as read-only, and many others) are of a more substantial and
realistic time-saver than skimming a few keystrokes at the top of a file.
Are keystrokes wasted on documentation also?

This reasoning seems kinda' weak, Ben. You're suggesting breaking backward
compatability for all existing code, by changing all the module names within
the "standard" library. Yet, at the same time, you see more benefit in
saving a keystroke or two than fully isolating the library namespace? I'd
like to understand this correctly, so please clarify?


p.s. KoochKoochyKooKode would not make an ideal prefix ...

Jun 01 2005

"Ben Hinkle" <ben.hinkle gmail.com> writes:

"Kris" <fu bar.com> wrote in message news:d7lgs8$2or1$1 digitaldaemon.com...
 "Ben Hinkle" <ben.hinkle gmail.com> wrote in message
 news:d7ldo3$2m81$1 digitaldaemon.com...
 "Kris" <fu bar.com> wrote in message


 If you do this, Ben,


 quick note: I'm not doing anything. Walter would do the changing. I'm 
 just
 talking :-)

 then please add a "phobos." prefix to the entire
 package. Phobos currently pollutes the top-level import namespace ~




 poor form, and hardly politically correct.


 I'm not sure what you mean here by pollutes. How would phobos prefix be


 polluting than std or d or anything else?



 Phobos currently has two root namespaces: std and etc. You're suggesting
 adding another:
 <quote>
 The most obvious choice is to change "std" to "d" and move "std.c.foo" to
 "c.foo".
 </quote>


Oh ok - you're talking about the "c" and "d" instead of just "std".

 Do you think this would be the end of it? I don't.


ok. I do.

 What if I already had a
 root namespace called "d", or "c", or "io", or "math"?


Then those packages would conflict. Anyone out there have a "c" or "d" root 
packages? I'd be curious to know. It's like the "java" package in Java but 
for D.

 Such things have a
 propensity to collide with packages designed and built independently. I
 don't think it requires much imagination to see what a mess things could
 become. There's good reason why other libraries have a single, unique root
 name. Other than phobos, I don't know of another notable D library that is
 not singly rooted.


True - a single root would be nice but I don't give that as much weigh as 
the other factors. I'm more focused on the names, the probability of 
conflicts and the usability of the resolutions to the conflicts.

 Examine domain-names for some guidance on the subject?


ok. you mean like everything is ".com"? :-)
I guess I don't know what you mean.

 If, as you say, it's a simple mechanical upgrade, then should we not do
 this
 instead?:

 # import phobos.x.y;


 The upgrade is mechanical but the phobos prefix has a couple downsides
 long-term IMHO: 1) not as pretty as std or d, 2) longer to type. We could
 mechanically change the prefix to foo (as suggested jokingly earlier) but
 that doesn't mean we should.



 1) Pretty?  :-D

 I'll assume you're serious for the moment, and ask if we should change the
 name of the library to something prettier also? How about "Tiffany", or
 "BabyDoll", or "KoochyKoochyKooKode" ?


uh, ok. I don't consider those as pretty (though I know you are kidding). 
You don't like pretty things? (or how about Dirty Pretty Things or whatever 
that movie was called). Substitute the phrase "aesthetically pleasing" for 
"pretty" if "pretty" doesn't do it for you. By "pretty" I also mean d.stdio 
and friends are more pretty than std.stdio and friends.

 2) Takes longer to type.  Hmm. I can't imagine anyone wasting time on an
 empirical study or some such, but the time it takes to type an import
 statement must be rather low on the scale of time consumed by design,
 development, debugging, and maintenance of the code itself.  I'd like to
 quietly suggest that adding further robust development features to the
 language (such as read-only, and many others) are of a more substantial 
 and
 realistic time-saver than skimming a few keystrokes at the top of a file.
 Are keystrokes wasted on documentation also?


Given the choice between typing and reading "d.foo" and "phobos.foo" my 
fingers and eyes prefer "d.foo". YMMV

 This reasoning seems kinda' weak, Ben. You're suggesting breaking backward
 compatability for all existing code, by changing all the module names 
 within
 the "standard" library. Yet, at the same time, you see more benefit in
 saving a keystroke or two than fully isolating the library namespace? I'd
 like to understand this correctly, so please clarify?


Walter's post describing the std choice said he prefered "d" over std but 
backed off because of the variable conflict and greppability. I don't think 
he should have given up on his preferred choice so easily. Everyone is 
entitled to their own opinions so you can disagree and that's fine. If you 
consider the argument for "d" and "c" as weak then that ok with me. I happen 
to think the short term pain of running a search-replace is worth the 
long-term benefit.

 p.s. KoochKoochyKooKode would not make an ideal prefix ...


agreed.

Jun 01 2005

"Kris" <fu bar.com> writes:

"Ben Hinkle" <ben.hinkle gmail.com> wrote ...
<snip>
 Phobos currently has two root namespaces: std and etc. You're suggesting
 adding another:
 <quote>
 The most obvious choice is to change "std" to "d" and move "std.c.foo"




 "c.foo".
 </quote>


 Oh ok - you're talking about the "c" and "d" instead of just "std".

 Do you think this would be the end of it? I don't.


 ok. I do.


The "etc" package was apparently just ostracized from phobos. Something else
is bound to come along, Ben. It always does, because we don't live in a
static world.


 What if I already had a
 root namespace called "d", or "c", or "io", or "math"?


 Then those packages would conflict. Anyone out there have a "c" or "d"


 packages? I'd be curious to know. It's like the "java" package in Java but
 for D.


It would be rather short-sighted for someone to do that; just as it would be
for phobos.


 Such things have a
 propensity to collide with packages designed and built independently. I
 don't think it requires much imagination to see what a mess things could
 become. There's good reason why other libraries have a single, unique




 name. Other than phobos, I don't know of another notable D library that




 not singly rooted.


 True - a single root would be nice but I don't give that as much weigh as
 the other factors. I'm more focused on the names, the probability of
 conflicts and the usability of the resolutions to the conflicts.


I see.  We'll agree to disagree, then <g>


 2) Takes longer to type.  Hmm. I can't imagine anyone wasting time on an
 empirical study or some such, but the time it takes to type an import
 statement must be rather low on the scale of time consumed by design,
 development, debugging, and maintenance of the code itself.  I'd like to
 quietly suggest that adding further robust development features to the
 language (such as read-only, and many others) are of a more substantial




 and
 realistic time-saver than skimming a few keystrokes at the top of a




 Are keystrokes wasted on documentation also?


 Given the choice between typing and reading "d.foo" and "phobos.foo" my
 fingers and eyes prefer "d.foo". YMMV


If one chooses to blindly ignore the benefits of an isolated namespace, then
this topic boils down to nothing more than a personal choice based entirely
upon aesthetics and habit. I mistakenly thought it was something just a wee
bit more important than that?


 This reasoning seems kinda' weak, Ben. You're suggesting breaking




 compatability for all existing code, by changing all the module names
 within
 the "standard" library. Yet, at the same time, you see more benefit in
 saving a keystroke or two than fully isolating the library namespace?




 like to understand this correctly, so please clarify?


 Walter's post describing the std choice said he prefered "d" over std but
 backed off because of the variable conflict and greppability. I don't


 he should have given up on his preferred choice so easily. Everyone is
 entitled to their own opinions so you can disagree and that's fine. If you
 consider the argument for "d" and "c" as weak then that ok with me. I


 to think the short term pain of running a search-replace is worth the
 long-term benefit.


What you describe does not appear to acknowledge the possibility of
libraries other than Phobos; so we'll just disagree. That's cool.


 p.s. KoochKoochyKooKode would not make an ideal prefix ...


 agreed.


:)

Jun 01 2005

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Kris wrote:

 Phobos currently has two root namespaces: std and etc. You're suggesting
 adding another:
 <quote>
 The most obvious choice is to change "std" to "d" and move "std.c.foo" to
 "c.foo".
 </quote>


I think that the Phobos (D standard library) namespace is "std",
and that "etc" is for Deimos (i.e. user contributions to Phobos)...

Here are the docs: http://www.digitalmars.com/d/phobos.html,
http://svn.dsource.org/projects/deimos/trunk/docs/intro.html

The only file left in a standard installation "etc" is "/c/zlib.d"
( which I have already flagged as a bug :-) ) and some C/C++ code.

Doesn't seem to be many etc. modules left on Dsource either, except
the Arcane Jill's old modules with the "unusable" license agreement ?

 Do you think this would be the end of it? I don't. What if I already had a
 root namespace called "d", or "c", or "io", or "math"? Such things have a
 propensity to collide with packages designed and built independently. I
 don't think it requires much imagination to see what a mess things could
 become. There's good reason why other libraries have a single, unique root
 name. Other than phobos, I don't know of another notable D library that is
 not singly rooted.


With a few notable exceptions (like: crc32.d, gcstats.d, etc/c/zlib.d),
then Phobos is also single-rooted - in the "std" namespace hierarchy ?

(I don't really consider the "internal" classes a part of Phobos,
and haven't checked the latest Ares package for any changes to "std")

I thought the whole topic here was renaming "std" to something else.
(and possibly renaming "std.c" to something outside the Phobos tree)

And I thought fixing Phobos was more important than renaming the dir ?
(or maybe I just didn't think "d" had enough merits to replace "std")

--anders

Jun 02 2005

D Programming

C/C++ Programming

Other

digitalmars.D - should std package be renamed?