I prefer lang to *any* of the acronyms and contractions (apart from lang, of
course, he he)

But I still prefer d



"Ilya Minkov" <midiclub@tiscali.de> wrote in message news:bn8bm4$7q4$1@digitaldaemon.com...
> I prefer D over d, and over most of the other acronyms. Plese not anything on the "sdl", "dsl", and so on theme. If you go that way, acronyms would have a much higher recycling rate than code!
>
> What i find neat is "lang" or something alike. :)
>
> -eye
>
> Matthew Wilson wrote:
> > As you can see from the group, everyone prefers d to D, irrespective of whether they prefer mutli-letter over d/D.
> >
> > Can we start by changing D.win32.registry to d.win32.registry for 0.75,
and
> > move from there unless and until we encounter any bumps in the road?
>

I think the "dmd" prefix should be used for the all 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())
I also wait for longtime the next release of DIDE... I hope it will be "cleaner"
(no double paranthesis, quotes etc...). And a bit more configurable...
The other opinion I agree is that *nothing* should be definitive till the no.
1.0 release version. Building on artifacts is worse than anything else. I would
like a different property definition, the "protected" import keyword (or smthink
like this)...

What about the "dig"? Somebody works on it?

Ok, I hope I harmed no one...

In article <bn8bte$82u$1@digitaldaemon.com>, Matthew Wilson says...
>
>I prefer lang to *any* of the acronyms and contractions (apart from lang, of
>course, he he)
>
>But I still prefer d
>
>
>
>"Ilya Minkov" <midiclub@tiscali.de> wrote in message news:bn8bm4$7q4$1@digitaldaemon.com...
>> I prefer D over d, and over most of the other acronyms. Plese not anything on the "sdl", "dsl", and so on theme. If you go that way, acronyms would have a much higher recycling rate than code!
>>
>> What i find neat is "lang" or something alike. :)
>>
>> -eye
>>
>> Matthew Wilson wrote:
>> > As you can see from the group, everyone prefers d to D, irrespective of whether they prefer mutli-letter over d/D.
>> >
>> > Can we start by changing D.win32.registry to d.win32.registry for 0.75,
>and
>> > move from there unless and until we encounter any bumps in the road?
>>
>
>

Sean L. Palmer wrote:
> "Charles Sanders" <sanders-consulting@comcast.net> wrote in message
> news:bn75j8$1m5u$1@digitaldaemon.com...
> 
>>Also, what is win32 / linux specifc stuff doing in the library ?
> 
> Shouldn't
> 
>>phobos just contain platform indepenent functions, like C's ?
> 
> 
> That's a really good point.
> 
> I agree and think it'd be best to keep the win32 and linux modules in some
> other namespace besides the standard library.

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

OK, me too, I like the "dsl" prefix...

In article <bn8435$2vjq$1@digitaldaemon.com>, Sean L. Palmer says...
>
>Who knows somebody in marketing?  Ask them!!
>
>I vote for dsl (D Standard Library).
>
>Sean
>
>"Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> wrote in message news:bn75am$1lou$1@digitaldaemon.com...
>> Ok. Here's where I see the situation. We have several options
>>
>> 1. D
>> 2. d
>> 3. phobos
>> 4. std
>> 5. stdd
>> 6. lang
>> 7. some other multi-letter prefix
>
>

> 1. D
> 2. d
> 3. phobos
> 4. std
> 5. stdd
> 6. lang
> 7. some other multi-letter prefix

My vote would be on "lang".

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

Matthew Wilson wrote:
> Ok. Here's where I see the situation. We have several options
> 
> 1. D
> 2. d
> 3. phobos
> 4. std
> 5. stdd
> 6. lang
> 7. some other multi-letter prefix
> 

I think I like std and lang.  They're used in C++ and Java; people coming from those languages will understand what they mean instantly, and people who know neither won't have much trouble figuring it out. You also get that with d/D, but one character identifiers are just begging to cause namespace conflicts.

Come to think of it, if it's going to be d or D, the latter is probably better *because* it breaks the rules.  That lends the impression that it's special somehow. (and it is, on one level)  It's also a little less likely to cause namespace collisions; people use single-character locals all the time, but rarely uppercase.

 -- andy

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

I like this idea.

"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

> I totally agree XML stuff should'nt be in there!
>

Could you please explain why? XML is common and in many modern languages. I don't particularly like XML much but I don't see what the big deal is.