In article <bn8qg4$s9h$1@digitaldaemon.com>, Lars Ivar Igesund says...
>
>
>"Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> wrote in message news:bn7bt2$1ub9$1@digitaldaemon.com...
>> As you can see from the group, everyone prefers d to D, irrespective of whether they prefer mutli-letter over d/D.
>
>I think I like D better than d because it stand out.
>
>This means that I vote for 'std'. (dsl is to much broadband for me.=)
>
>Lars Ivar Igesund
>
>

Of course, 'std' carries its own negative connotations... ;)

-Jon

>
>Yes, I agree that having OS-specific stuff as part of the standard library is a bad thing.
>
>My reasons, however, are a bit different than the ones that were mentioned up to now.
>
>One important thing to consider is that the standard library should stay stable. If you add new functionality then code using that functionality will not compile with earlier releases of the compiler. That is something that HAS to be avoided, or we end up in a versioning hell for even the most simple programs.
>
>I think most people will agree that it is not possible to incorporate all the functionality of an OS API in the standard library. Especially the Windows API continues to grow continuously. So what we would end up is a snapshot of the functionality that is currently considered the most important. In 4 years half of that will be deprecated and the Windows API will have moved on. Since we cannot really update the standard library, it will become less and less useful up to a point where it doesn't make sense to use it anymore.
>
>This kind of thing really has to be done with an external library that doesn't have the kind of upgrade restrictions that the core compiler package has.
>
>Hauke
>

Ouch. Really good points here. Maybe the 'core' libraries would have to be
os-independent, with a second set of 'less-standard' libraries that may or may
not be os-dependent. The compiler wouldn't ship with those, but maybe they could
be part of a seperate SDK, and would be 'official' more or less.
The big thing I have been thinking of is the windowing/GUI toolkits. It would be
nice if we could provide a standard GUI toolkit for D (i.e. swing for Java) but
the problem of platform dependence is too big of a hassle. However, if we could
have sort of a 'blessed' toolkit for each platform, (i.e. Dig for Windows, DUI
for Linux) then include both of those in the SDK, I think it might make
acceptance of the language a little easier for people.

-Jon

"Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> wrote in message news:bn8530$30m5$1@digitaldaemon.com...
> > > Now maybe COM is not the best example, because the likelihood of our
> doing
> > a
> > > Linux version is pretty slim (although maybe that's not the case for
> > Mac!?),
> > > but I'm sure you can extrapolate to other things. Networking, for
> example.
> > > We'd be idiotic to not support using IO Completion ports on Win32 implementations, but this doesn't work for UNIX.
> >
> > I fully expect the runtime library to be using os-specific functions
under
> > the hood.
>
> But what if those under-the-hood things are also to be provided as
external
> interfaces?

Then the standard library would import and use those external libraries just like any other library with dependencies would.

Sean

"Felix" <Felix_member@pathlink.com> wrote in message news:bn8eeb$bhq$1@digitaldaemon.com...
> I think the "dmd" prefix should be used for the all phobos.


DMD is an acronym for "Digital Mars D" and that apparently is why Walter doesn't want to use Phobos?

> Also, I would like an import modifier e.g. like
> "protected" import modulename;
> to allow the imported symbols be acessed but only via
modulename.methodname()
> syntax... It is sometimes useful. The default should be a "public" import
(i.e.
> ascessing via methodname())

Sounds good.

Sean

Personally, I still like d, and we have to hear from Walter whether all this debate is fatuous.

However, in anticipation that Walter is moveable, and most dislike d (or D),
how about the following:

    lang - language elements of the standard library
    std - the rest of the standard library, including those
platform-specific parts,

or, for those not scared by a little more typing,

    std.lang - language
    std.core - core, platform independent aspects
    std.platform - platform-specific parts


Object, Exception would be in

    std.lang

File, RegExp, Thread, Stream, etc. would be in

    std.core

Things like Win32 and Linux parts would be in

    std.platform.win32
    std.platform.linux

then we could have things like the Endian enumeration (currently lurking
inside D.win32.registry), in

    std.platform.ordering

or

    std.platform.endian


Anyone hate/love/need-to-enhance it? We need to end this debate soon, as I'm working on more libs for 0.75 (or 0.76, maybe) and I don't want to keep changing modules. I'm sure many others are in the same boat.

Matthew

"Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> wrote in news:bn9att$1mss$1@digitaldaemon.com:

> Personally, I still like d, and we have to hear from Walter whether all this debate is fatuous.
> 
> However, in anticipation that Walter is moveable, and most dislike d
> (or D), how about the following:
> 
>     lang - language elements of the standard library
>     std - the rest of the standard library, including those
> platform-specific parts,

First choice

> or, for those not scared by a little more typing,
> 
>     std.lang - language
>     std.core - core, platform independent aspects
>     std.platform - platform-specific parts

Second choice

I think it's a good idea.

"Julio César Carrascal Urquijo" <adnoctum@phreaker.net> wrote in message news:bn8k6r$jfk$2@digitaldaemon.com...
> > Also, I would like an import modifier e.g. like
> > "protected" import modulename;
> > to allow the imported symbols be acessed but only via
> modulename.methodname()
> > syntax... It is sometimes useful. The default should be a "public"
import
> (i.e.
> > ascessing via methodname())
>
>
> This it's really nice and would avoid lot's of problems I'm having with win32 imports.
>
> Walter... Please! Could we have that one?
>
>

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bn92qa$18t1$1@digitaldaemon.com...
> "Felix" <Felix_member@pathlink.com> wrote in message news:bn8eeb$bhq$1@digitaldaemon.com...
> > I think the "dmd" prefix should be used for the all phobos.
> DMD is an acronym for "Digital Mars D" and that apparently is why Walter doesn't want to use Phobos?

I thought nobody liked phobos <g>.

It is a good point that you may not want to tie the D language too closely to your company name.  It doesn't bother me personally though.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:bnc00v$2lpb$2@digitaldaemon.com...
>
> "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bn92qa$18t1$1@digitaldaemon.com...
> > "Felix" <Felix_member@pathlink.com> wrote in message news:bn8eeb$bhq$1@digitaldaemon.com...
> > > I think the "dmd" prefix should be used for the all phobos.
> > DMD is an acronym for "Digital Mars D" and that apparently is why Walter doesn't want to use Phobos?
>
> I thought nobody liked phobos <g>.