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

:)

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

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

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

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

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

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

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

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

"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d7ldo3$2m81$1@digitaldaemon.com...
>
> "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?


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