I agree. At least I don't like etc.

Lars Ivar Igesund

"Roberto Mariottini" <Roberto_member@pathlink.com> wrote in message news:bnqp2a$i4q$1@digitaldaemon.com...
> In article <bnn9a0$1o09$1@digitaldaemon.com>, Walter says... [...]
> >etc
> > There are lots of 'other' modules for D, and right now there is no
> > organized way to deal with them. There needs to be a place for them.
> > The etc heirarchy will mirror the standard one, i.e. there will
> > be etc.c, etc.os.windows, ... These will not be official parts of D
> > nor will they be standardized. However, candidates for standardization
> > will be drawn from etc. etc is the place for
> > not-quite-there-yet-but-still-useful modules.
>
> What does 'etc' stand for?
> I'd prefer 'ext', that means extension.
>
> Ciao
>
>

Roberto Mariottini wrote:
> 
> In article <bnn9a0$1o09$1@digitaldaemon.com>, Walter says... [...]
> >etc
> > There are lots of 'other' modules for D, and right now there is no
> > organized way to deal with them. There needs to be a place for them.
> > The etc heirarchy will mirror the standard one, i.e. there will
> > be etc.c, etc.os.windows, ... These will not be official parts of D
> > nor will they be standardized. However, candidates for standardization
> > will be drawn from etc. etc is the place for
> > not-quite-there-yet-but-still-useful modules.
> 
> What does 'etc' stand for?
> I'd prefer 'ext', that means extension.

I don't think we need to take this so literally.

Walter surely will find better places in std for most modules. I think its just an "default" case: "...and if we really don't know where to put a module, then we have still this place..."

If no-one likes it, just the better. Nothing should ever go there.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

Helmut Leitner wrote:

> I don't think we need to take this so literally.
> 
> Walter surely will find better places in std for most modules. I think its just an "default" case: "...and if we really don't
> know where to put a module, then we have still this place..."
> 
> If no-one likes it, just the better. Nothing should ever go there.

The less the better. Remember what happened to Java in this respect? javax.sql.* was intruduced containing JDBC 3.0 stuff. Now that it's part of JDK 1.4 it's still in javax since moving it would cause no end of compatibility problems.

Once in etc, it will stay in etc, so it's better to never put it there in the first place.

Just my personal opinion.

Regards

Elias

Helmut Leitner wrote:

>Roberto Mariottini wrote:
>  
>
>>In article <bnn9a0$1o09$1@digitaldaemon.com>, Walter says...
>>[...]
>>    
>>
>>>etc
>>>There are lots of 'other' modules for D, and right now there is no
>>>organized way to deal with them. There needs to be a place for them.
>>>The etc heirarchy will mirror the standard one, i.e. there will
>>>be etc.c, etc.os.windows, ... These will not be official parts of D
>>>nor will they be standardized. However, candidates for standardization
>>>will be drawn from etc. etc is the place for
>>>not-quite-there-yet-but-still-useful modules.
>>>      
>>>
>>What does 'etc' stand for?
>>I'd prefer 'ext', that means extension.
>>    
>>
>
>I don't think we need to take this so literally.
>
>Walter surely will find better places in std for most modules. I think its just an "default" case: "...and if we really don't
>know where to put a module, then we have still this place..."
>
>If no-one likes it, just the better. Nothing should ever go there.
>
>  
>

I think etc would be a good place to get early access to new ideas and modules, like in openGL's extension mechanism.  There may be allot of (constructive) argument about one aspect of something, and it could be threshed out in more then one prototype implementation, parhaps by several different companies for example.  When one implementation becomes widely accepted, it would be moved over the the main lot as a new library.  It's a good for people who just want to get on with the coding.

But I think ext is a better name for that.

user@domain.invalid wrote:

> Once in etc, it will stay in etc, so it's better to never put it there in the first place.
> 
> Just my personal opinion.
> 
> Regards
> 
> Elias

hm.  That brings up an idea.  The etc.blah module could later be rewritten as:

deprecated import proper.place.to.put.blah;

Supposing that imports can be marked as deprecated.  So the etc package would probably get pretty bloaty over time, but the compiler would bitch at everybody who tries to use it, and it would all just be redirecting, so size and so forth would not suffer.

(better to put it in the right place right off the bat, sure, but that's not as easy as it sounds sometimes)

 -- andy

> > --------------------
> > std.os
> >     Access to platform specific functionality.
> >     ...
> >
> >
> > Modified:
> > --------------------
> > std.os
> >     Access to OS-level, platform-independent functionality.
> >     ...
> >
> > Or do I misunderstand something?
> I think you do.
>
> The way I read it, "std.os" would only contain code that relates to platform-dependent (a/k/a platform-specific) functionality.  It would probably contain only a series of directories: "windows", "linux", and any other platforms with D implementations.


Well, dunno, but even without knowing how this really
is in D, I'm still almost sure a namespace node is not
restricted to contain either leaf nodes or another
subnamespaces.

Cheers,
Sz.

Andy Friesen wrote:

> user@domain.invalid wrote:
> 
>> Once in etc, it will stay in etc, so it's better to never put it there in the first place.
>>
>> Just my personal opinion.
>>
>> Regards
>>
>> Elias
> 
> 
> hm.  That brings up an idea.  The etc.blah module could later be rewritten as:
> 
> deprecated import proper.place.to.put.blah;
> 
> Supposing that imports can be marked as deprecated.  So the etc package would probably get pretty bloaty over time, but the compiler would bitch at everybody who tries to use it, and it would all just be redirecting, so size and so forth would not suffer.
> 
> (better to put it in the right place right off the bat, sure, but that's not as easy as it sounds sometimes)

First of all: sorry for not having configured my email address properly, it shuld be fixed now.

The redirect idea sounds nice, and IMHO it's the only thing that works. Java has provided us with a very good warning. The redirect idea is a good workaround but you have to agree, it's a hack. :-)

Elias

"Roberto Mariottini" <Roberto_member@pathlink.com> wrote in message news:bnqp2a$i4q$1@digitaldaemon.com...
> What does 'etc' stand for?

'etcetera, etcetera, etcetera' (doing my best Yul Brynner impersonation)

"J Anderson" <anderson@badmama.com.au.REMOVE> wrote in message news:bnr4eh$10q3$1@digitaldaemon.com...
> I think etc would be a good place to get early access to new ideas and modules, like in openGL's extension mechanism.  There may be allot of (constructive) argument about one aspect of something, and it could be threshed out in more then one prototype implementation, parhaps by several different companies for example.  When one implementation becomes widely accepted, it would be moved over the the main lot as a new library.  It's a good for people who just want to get on with the coding.

Yes, exactly.

In article <bnn9a0$1o09$1@digitaldaemon.com>, Walter says...


>std.c
> Contains D interfaces to standard C library functions, like std.c.stdio, std.c.stdlib, std.c.math.

kinda like puting together stawberies and chilly peppers because they are the same color...

(I know Walter will never change his mind (reverse psychology)
but the rest of you has to agree ;)

Ant