www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - should std package be renamed?

reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
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
next sibling parent 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
prev sibling next sibling parent 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
prev sibling next sibling parent reply 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
next sibling parent reply "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
parent reply 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
next sibling parent reply "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
next sibling parent reply 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
parent "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
prev sibling parent reply 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
next sibling parent reply 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
parent reply 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
parent "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
prev sibling parent reply =?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
parent 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
prev sibling next sibling parent "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
prev sibling next sibling parent 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
prev sibling next sibling parent 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
prev sibling next sibling parent reply "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
parent reply 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
parent "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
prev sibling parent 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
prev sibling next sibling parent 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
prev sibling parent reply 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
next sibling parent reply "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
parent reply 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
parent "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
prev sibling parent 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
prev sibling next sibling parent "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
prev sibling parent reply =?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
parent reply "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
next sibling parent reply =?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
parent reply "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
parent reply =?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
parent reply "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
parent =?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
prev sibling parent reply "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
next sibling parent 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
prev sibling parent reply "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
next sibling parent reply 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
parent reply "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
parent reply 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
next sibling parent reply 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
next sibling parent reply 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
next sibling parent 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
prev sibling parent 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
prev sibling next sibling parent 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
prev sibling next sibling parent 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
prev sibling parent "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
prev sibling parent =?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
prev sibling parent reply "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
next sibling parent reply "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
parent "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
prev sibling parent =?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