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

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

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

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

"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.

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.

"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.

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

"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

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