www.digitalmars.com         C & C++   DMDScript  

D - phobos docs

reply "Lars Ivar Igesund" <larsivi stud.ntnu.no> writes:
Is the phobos docs updated recently? I can't find
D.win32.registry anywhere (on the website). Also,
what works?
Can everything have D in front of it? What about d?
What about nothing? In short: What are our choices
when importing something from phobos?

Lars Ivar Igesund
Oct 22 2003
next sibling parent "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
The registry doco at http://synsoft.org/d/libraries/doc/index.html are
mostly accurate, with a few new features not represented.

The registry.d file is fully stocked with Doxygen tags, but it has not been
built in the new D.win32.registry guise (it was formerly
synsoft.win32.registry).

Naturally, this should be done at some point, but I'm behind on some other
things.

Matthew

"Lars Ivar Igesund" <larsivi stud.ntnu.no> wrote in message
news:bn5gi1$2f17$1 digitaldaemon.com...

 Is the phobos docs updated recently? I can't find
 D.win32.registry anywhere (on the website). Also,
 what works?
 Can everything have D in front of it? What about d?
 What about nothing? In short: What are our choices
 when importing something from phobos?

 Lars Ivar Igesund
Oct 22 2003
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Lars Ivar Igesund" <larsivi stud.ntnu.no> wrote in message
news:bn5gi1$2f17$1 digitaldaemon.com...

 Is the phobos docs updated recently? I can't find
 D.win32.registry anywhere (on the website). Also,
 what works?


I'll go with Matthew's answer!


 Can everything have D in front of it? What about d?
 What about nothing? In short: What are our choices
 when importing something from phobos?


Eventually, the packages will look like:

D.???    modules that are available for all D implementations
D.win32.???   modules that only work on win32
D.linux.???    modules that only work on linux
C.???    modules that come from C
Oct 22 2003
next sibling parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
I've been thinking about this module naming stuff, and considering C++'s
approach.

Clearly one of the reasons they chose std was because it was at least a bit
unambiguous (three letters!)

I'm starting to wonder whether Helmut's notion of the standard library's
having something longer than D (or d) makes sense.

Separately, I still don't see any difference between D and d, other than D
is less consistent, which will be a permanent flaw on the language. Having
people not be able to write d in a language called D doesn't seen a great
hardship. It's not exactly difficult to do a global whole-word search and
replace to change all d or D into d_ and D_ (or whatever).

I know I'm wandering a bit, but *please* let us have d.win32.etc.


btw, can you explain what a C module is? Is this a c library with function
declarations only in D?


"Walter" <walter digitalmars.com> wrote in message
news:bn6bje$hk7$2 digitaldaemon.com...

 "Lars Ivar Igesund" <larsivi stud.ntnu.no> wrote in message
 news:bn5gi1$2f17$1 digitaldaemon.com...

 Is the phobos docs updated recently? I can't find
 D.win32.registry anywhere (on the website). Also,
 what works?


 I'll go with Matthew's answer!


 Can everything have D in front of it? What about d?
 What about nothing? In short: What are our choices
 when importing something from phobos?


 Eventually, the packages will look like:

 D.???    modules that are available for all D implementations
 D.win32.???   modules that only work on win32
 D.linux.???    modules that only work on linux
 C.???    modules that come from C
Oct 22 2003
next sibling parent reply Patrick Down <Patrick_member pathlink.com> writes:
In article <bn6sef$19kb$1 digitaldaemon.com>, Matthew Wilson says...

I've been thinking about this module naming stuff, and considering C++'s
approach.

Clearly one of the reasons they chose std was because it was at least a bit
unambiguous (three letters!)


HEY!   Why can't we use std?  standard-d?
Oct 22 2003
parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:bn6skf$19si$1 digitaldaemon.com...

 In article <bn6sef$19kb$1 digitaldaemon.com>, Matthew Wilson says...

I've been thinking about this module naming stuff, and considering C++'s
approach.

Clearly one of the reasons they chose std was because it was at least a




bit

unambiguous (three letters!)


 HEY!   Why can't we use std?  standard-d?


Well I guess no reason, other than Walter (and others, me included) want D.
The main contention is that it seems that Walter's the only one (who's
publicly expressed, anyway) the preference for D over d, despite the
inconsistency. Do you have a preference in that regard?
Oct 22 2003
parent reply Patrick Down <Patrick_member pathlink.com> writes:
In article <bn6tgo$1b4d$1 digitaldaemon.com>, Matthew Wilson says...

"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:bn6skf$19si$1 digitaldaemon.com...

 In article <bn6sef$19kb$1 digitaldaemon.com>, Matthew Wilson says...

I've been thinking about this module naming stuff, and considering C++'s
approach.

Clearly one of the reasons they chose std was because it was at least a




bit

unambiguous (three letters!)


 HEY!   Why can't we use std?  standard-d?


Well I guess no reason, other than Walter (and others, me included) want D.
The main contention is that it seems that Walter's the only one (who's
publicly expressed, anyway) the preference for D over d, despite the
inconsistency. Do you have a preference in that regard?


If you held my arm against my back and forced me to make a decision
I would say d.   But I really dislike using a one letter name.
Oct 22 2003
parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
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

The primary bifurcation on opinion is whether it is d/D or a multi-letter.
Personally I'm still in two minds about this, although I lean towards d/D

Secondary to that, therefore, is whether on for former case we go for d or
for D. I lean towards d, and think that in either case it's not unreasonable
to reserve the name of the language (in both cases).

For the case of multi-letter prefixes, phobos is ruled out because of its
(Digital) Mars specificity, but the other contenders seem reasonable, albeit
somewhat prosaic.

It would be useful if everyone could express their opinions on the main
question of d/D vs multi-letter, *and* the secondary questions.

Is there a possibility that one of you web-enabled kinda guys could organise
a vote? Helmut, what about a place on your wiki stuff?

Anyway, it may well be that Walter's just decided, and that's it, but until
he says he is immovable I would like to explore. This is a very important
issue that, once fixed, cannot be changed, so it's worth a little of all our
consideration.

Cheers


-- 
Matthew Wilson

STLSoft moderator and C++ monomaniac       (http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
(www.synesis.com.au/articles.html#columns)

"If i'm curt with you it's because time is a factor. I think fast, I talk
fast, and I need you guys to act fast" -- Mr Wolf

----------------------------------------------------------------------------
---


"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:bn73fk$1jfo$1 digitaldaemon.com...

 In article <bn6tgo$1b4d$1 digitaldaemon.com>, Matthew Wilson says...

"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:bn6skf$19si$1 digitaldaemon.com...

 In article <bn6sef$19kb$1 digitaldaemon.com>, Matthew Wilson says...

I've been thinking about this module naming stuff, and considering








C++'s

approach.

Clearly one of the reasons they chose std was because it was at least








a

bit

unambiguous (three letters!)


 HEY!   Why can't we use std?  standard-d?


Well I guess no reason, other than Walter (and others, me included) want




D.

The main contention is that it seems that Walter's the only one (who's
publicly expressed, anyway) the preference for D over d, despite the
inconsistency. Do you have a preference in that regard?


 If you held my arm against my back and forced me to make a decision
 I would say d.   But I really dislike using a one letter name.
Oct 22 2003
next sibling parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
I vote phobos, its the name of the runtime library why cant other vendors
call it that also ?

Also, what is win32 / linux specifc stuff doing in the library ?  Shouldn't
phobos just contain platform indepenent functions, like C's ?

I pray that D is not selected, although d gets my vote if we cant have
phobos.

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

 The primary bifurcation on opinion is whether it is d/D or a multi-letter.
 Personally I'm still in two minds about this, although I lean towards d/D

 Secondary to that, therefore, is whether on for former case we go for d or
 for D. I lean towards d, and think that in either case it's not


unreasonable

 to reserve the name of the language (in both cases).

 For the case of multi-letter prefixes, phobos is ruled out because of its
 (Digital) Mars specificity, but the other contenders seem reasonable,


albeit

 somewhat prosaic.

 It would be useful if everyone could express their opinions on the main
 question of d/D vs multi-letter, *and* the secondary questions.

 Is there a possibility that one of you web-enabled kinda guys could


organise

 a vote? Helmut, what about a place on your wiki stuff?

 Anyway, it may well be that Walter's just decided, and that's it, but


until

 he says he is immovable I would like to explore. This is a very important
 issue that, once fixed, cannot be changed, so it's worth a little of all


our

 consideration.

 Cheers


 -- 
 Matthew Wilson

 STLSoft moderator and C++ monomaniac       (http://www.stlsoft.org)
 Contributing editor, C/C++ Users Journal
 (www.synesis.com.au/articles.html#columns)

 "If i'm curt with you it's because time is a factor. I think fast, I talk
 fast, and I need you guys to act fast" -- Mr Wolf

 --------------------------------------------------------------------------


--

 ---


 "Patrick Down" <Patrick_member pathlink.com> wrote in message
 news:bn73fk$1jfo$1 digitaldaemon.com...

 In article <bn6tgo$1b4d$1 digitaldaemon.com>, Matthew Wilson says...

"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:bn6skf$19si$1 digitaldaemon.com...

 In article <bn6sef$19kb$1 digitaldaemon.com>, Matthew Wilson says...

I've been thinking about this module naming stuff, and considering








 C++'s

approach.

Clearly one of the reasons they chose std was because it was at










least

 a

bit

unambiguous (three letters!)


 HEY!   Why can't we use std?  standard-d?


Well I guess no reason, other than Walter (and others, me included)






want

 D.

The main contention is that it seems that Walter's the only one (who's
publicly expressed, anyway) the preference for D over d, despite the
inconsistency. Do you have a preference in that regard?


 If you held my arm against my back and forced me to make a decision
 I would say d.   But I really dislike using a one letter name.
Oct 22 2003
next sibling parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
 I vote phobos, its the name of the runtime library why cant other vendors
 call it that also ?


I guess it just invites those NIH instincts to rise. I guess the thinking is
it's nice how Java's std libraries are under java, so why can't D have the
same?


 Also, what is win32 / linux specifc stuff doing in the library ?


Why shouldn't platform specific stuff be in the library? This is a language
about usability and efficiency, not some notional purity. If we want
everything to be platform/technology independent, we're going to have some
very unweidly and inefficient code, like .. erm .. Java.

In any case, why is it only platforms that one should be independent of? One
could equally argue that XML stuff shouldn't be in there. Or UDP vs TCP:
shouldn't it all be an invisible

Of course no-one's saying that common functionality, like file-handling,
should be implemented in a specific fashion, but do you not think there are
platform-specific features that we would want in?

Consider the case of COM. Imagine for a moment that COM really had made a
successful transition to Linux. In this case, when we implement the
platform-independent D COM libraries we're a bit stuck. The Win32 versions
of the D.com modules will have to reference some "external" modules, in
order to implement their registration functionality.

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.



  Shouldn't phobos just contain platform indepenent functions, like C's ?


Do you really want to hold up the C runtime library as an example of the
best libraries there can be? Surely not.


 I pray that D is not selected, although d gets my vote if we cant have
 phobos.


Agreed


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

 The primary bifurcation on opinion is whether it is d/D or a




multi-letter.

 Personally I'm still in two minds about this, although I lean towards




d/D

 Secondary to that, therefore, is whether on for former case we go for d




or

 for D. I lean towards d, and think that in either case it's not


 unreasonable

 to reserve the name of the language (in both cases).

 For the case of multi-letter prefixes, phobos is ruled out because of




its

 (Digital) Mars specificity, but the other contenders seem reasonable,


 albeit

 somewhat prosaic.

 It would be useful if everyone could express their opinions on the main
 question of d/D vs multi-letter, *and* the secondary questions.

 Is there a possibility that one of you web-enabled kinda guys could


 organise

 a vote? Helmut, what about a place on your wiki stuff?

 Anyway, it may well be that Walter's just decided, and that's it, but


 until

 he says he is immovable I would like to explore. This is a very




important

 issue that, once fixed, cannot be changed, so it's worth a little of all


 our

 consideration.

 Cheers


 -- 
 Matthew Wilson

 STLSoft moderator and C++ monomaniac       (http://www.stlsoft.org)
 Contributing editor, C/C++ Users Journal
 (www.synesis.com.au/articles.html#columns)

 "If i'm curt with you it's because time is a factor. I think fast, I




talk

 fast, and I need you guys to act fast" -- Mr Wolf


 --------------------------------------------------------------------------
 --

 ---


 "Patrick Down" <Patrick_member pathlink.com> wrote in message
 news:bn73fk$1jfo$1 digitaldaemon.com...

 In article <bn6tgo$1b4d$1 digitaldaemon.com>, Matthew Wilson says...

"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:bn6skf$19si$1 digitaldaemon.com...

 In article <bn6sef$19kb$1 digitaldaemon.com>, Matthew Wilson










says...

I've been thinking about this module naming stuff, and considering








 C++'s

approach.

Clearly one of the reasons they chose std was because it was at










 least

 a

bit

unambiguous (three letters!)


 HEY!   Why can't we use std?  standard-d?


Well I guess no reason, other than Walter (and others, me included)






 want

 D.

The main contention is that it seems that Walter's the only one








(who's

publicly expressed, anyway) the preference for D over d, despite the
inconsistency. Do you have a preference in that regard?


 If you held my arm against my back and forced me to make a decision
 I would say d.   But I really dislike using a one letter name.
Oct 22 2003
next sibling parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
 I guess it just invites those NIH instincts to rise


NIH ?



 In any case, why is it only platforms that one should be independent of?


One

 could equally argue that XML stuff shouldn't be in there.


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


 Do you really want to hold up the C runtime library as an example of the
 best libraries there can be? Surely not.


Whats wrong with C library ?

But my main argument is not that we shouldn't have the functionality you
mentioned, I think we defeintly need that but I don't think it should be in
the one library that MUST be linked in.  C's lib is small and effecient,
thats where I was going with the C refrence.  All those other libs can be
implemeneted apart from phobos, so we can choose wether or not we want to
link them in ( and make our end executable larger) .

We can make them 'official' in some other respect ?  ( If thats a problem
? )

C

"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bn781a$1pal$1 digitaldaemon.com...

 I vote phobos, its the name of the runtime library why cant other




vendors

 call it that also ?


 I guess it just invites those NIH instincts to rise. I guess the thinking


is

 it's nice how Java's std libraries are under java, so why can't D have the
 same?


 Also, what is win32 / linux specifc stuff doing in the library ?


 Why shouldn't platform specific stuff be in the library? This is a


language

 about usability and efficiency, not some notional purity. If we want
 everything to be platform/technology independent, we're going to have some
 very unweidly and inefficient code, like .. erm .. Java.

 In any case, why is it only platforms that one should be independent of?


One

 could equally argue that XML stuff shouldn't be in there. Or UDP vs TCP:
 shouldn't it all be an invisible

 Of course no-one's saying that common functionality, like file-handling,
 should be implemented in a specific fashion, but do you not think there


are

 platform-specific features that we would want in?

 Consider the case of COM. Imagine for a moment that COM really had made a
 successful transition to Linux. In this case, when we implement the
 platform-independent D COM libraries we're a bit stuck. The Win32 versions
 of the D.com modules will have to reference some "external" modules, in
 order to implement their registration functionality.

 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.



  Shouldn't phobos just contain platform indepenent functions, like C's ?


 Do you really want to hold up the C runtime library as an example of the
 best libraries there can be? Surely not.


 I pray that D is not selected, although d gets my vote if we cant have
 phobos.


 Agreed


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

 The primary bifurcation on opinion is whether it is d/D or a




 multi-letter.

 Personally I'm still in two minds about this, although I lean towards




 d/D

 Secondary to that, therefore, is whether on for former case we go for






d

 or

 for D. I lean towards d, and think that in either case it's not


 unreasonable

 to reserve the name of the language (in both cases).

 For the case of multi-letter prefixes, phobos is ruled out because of




 its

 (Digital) Mars specificity, but the other contenders seem reasonable,


 albeit

 somewhat prosaic.

 It would be useful if everyone could express their opinions on the






main

 question of d/D vs multi-letter, *and* the secondary questions.

 Is there a possibility that one of you web-enabled kinda guys could


 organise

 a vote? Helmut, what about a place on your wiki stuff?

 Anyway, it may well be that Walter's just decided, and that's it, but


 until

 he says he is immovable I would like to explore. This is a very




 important

 issue that, once fixed, cannot be changed, so it's worth a little of






all

 our

 consideration.

 Cheers


 -- 
 Matthew Wilson

 STLSoft moderator and C++ monomaniac       (http://www.stlsoft.org)
 Contributing editor, C/C++ Users Journal
 (www.synesis.com.au/articles.html#columns)

 "If i'm curt with you it's because time is a factor. I think fast, I




 talk

 fast, and I need you guys to act fast" -- Mr Wolf




 --------------------------------------------------------------------------

 --

 ---


 "Patrick Down" <Patrick_member pathlink.com> wrote in message
 news:bn73fk$1jfo$1 digitaldaemon.com...

 In article <bn6tgo$1b4d$1 digitaldaemon.com>, Matthew Wilson says...

"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:bn6skf$19si$1 digitaldaemon.com...

 In article <bn6sef$19kb$1 digitaldaemon.com>, Matthew Wilson










 says...

I've been thinking about this module naming stuff, and














considering

 C++'s

approach.

Clearly one of the reasons they chose std was because it was at










 least

 a

bit

unambiguous (three letters!)


 HEY!   Why can't we use std?  standard-d?


Well I guess no reason, other than Walter (and others, me included)






 want

 D.

The main contention is that it seems that Walter's the only one








 (who's

publicly expressed, anyway) the preference for D over d, despite










the

inconsistency. Do you have a preference in that regard?


 If you held my arm against my back and forced me to make a decision
 I would say d.   But I really dislike using a one letter name.
Oct 22 2003
next sibling parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
"Charles Sanders" <sanders-consulting comcast.net> wrote in message
news:bn79m9$1rdq$1 digitaldaemon.com...

 I guess it just invites those NIH instincts to rise


 NIH ?


Not Invented Here. Apart from a propensity for thinking in binary, this is
about the most innate aspect of all software engineers.

Walter wrote his own C++ compiler because he didn't want to use anyone
else's. Then he wrote his own language because he didn't want to use anyone
else's.

I released STLSoft because one of the Boost's core libraries (no names, no
pack drill) said something so fundamentally stupid as a justification for a
(wrong) implemetation strategy that I just completely lost faith in their
ability to produce efficient and robust code. (Of course, they have produced
a lot of robust code, don't get me wrong, just explaining the instincts.)


 In any case, why is it only platforms that one should be independent of?


 One

 could equally argue that XML stuff shouldn't be in there.


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


 Do you really want to hold up the C runtime library as an example of the
 best libraries there can be? Surely not.


 Whats wrong with C library ?


Well, it's great that its got an ABI, but it gets that from C. There are
many many bad things about it. People only don't notice because they compare
it to the C++ standard libraries (STL, for the most part, excepted) against
which it looks orthogonal, efficient and neat.


 But my main argument is not that we shouldn't have the functionality you
 mentioned, I think we defeintly need that but I don't think it should be


in

 the one library that MUST be linked in.  C's lib is small and effecient,
 thats where I was going with the C refrence.  All those other libs can be
 implemeneted apart from phobos, so we can choose wether or not we want to
 link them in ( and make our end executable larger) .


If it's a library against which one is linking it doesn't matter how much it
has in it, does it? The linker will take what it needs. But that's beside
the point, we should/must have a set of libraries that make sense, and are
as interdependent as necessary, but no more. That's all still up in the air,
and your comments of the previous paragraph are as valid as what anyone else
thinks at this time.


 We can make them 'official' in some other respect ?  ( If thats a problem
 ? )


I think we're talking at cross purposes here. The standard library (AFAIUI)
is what ships with the D compiler as standard, and not necessary what is in
a specific .lib, or set of them. That's all still in the air


 C

 "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
 news:bn781a$1pal$1 digitaldaemon.com...

 I vote phobos, its the name of the runtime library why cant other




 vendors

 call it that also ?


 I guess it just invites those NIH instincts to rise. I guess the




thinking

 is

 it's nice how Java's std libraries are under java, so why can't D have




the

 same?


 Also, what is win32 / linux specifc stuff doing in the library ?


 Why shouldn't platform specific stuff be in the library? This is a


 language

 about usability and efficiency, not some notional purity. If we want
 everything to be platform/technology independent, we're going to have




some

 very unweidly and inefficient code, like .. erm .. Java.

 In any case, why is it only platforms that one should be independent of?


 One

 could equally argue that XML stuff shouldn't be in there. Or UDP vs TCP:
 shouldn't it all be an invisible

 Of course no-one's saying that common functionality, like file-handling,
 should be implemented in a specific fashion, but do you not think there


 are

 platform-specific features that we would want in?

 Consider the case of COM. Imagine for a moment that COM really had made




a

 successful transition to Linux. In this case, when we implement the
 platform-independent D COM libraries we're a bit stuck. The Win32




versions

 of the D.com modules will have to reference some "external" modules, in
 order to implement their registration functionality.

 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.



  Shouldn't phobos just contain platform indepenent functions, like C's






?

 Do you really want to hold up the C runtime library as an example of the
 best libraries there can be? Surely not.


 I pray that D is not selected, although d gets my vote if we cant have
 phobos.


 Agreed


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

 The primary bifurcation on opinion is whether it is d/D or a




 multi-letter.

 Personally I'm still in two minds about this, although I lean








towards

 d/D

 Secondary to that, therefore, is whether on for former case we go








for

 d

 or

 for D. I lean towards d, and think that in either case it's not


 unreasonable

 to reserve the name of the language (in both cases).

 For the case of multi-letter prefixes, phobos is ruled out because








of

 its

 (Digital) Mars specificity, but the other contenders seem








reasonable,

 albeit

 somewhat prosaic.

 It would be useful if everyone could express their opinions on the






 main

 question of d/D vs multi-letter, *and* the secondary questions.

 Is there a possibility that one of you web-enabled kinda guys could


 organise

 a vote? Helmut, what about a place on your wiki stuff?

 Anyway, it may well be that Walter's just decided, and that's it,








but

 until

 he says he is immovable I would like to explore. This is a very




 important

 issue that, once fixed, cannot be changed, so it's worth a little of






 all

 our

 consideration.

 Cheers


 -- 
 Matthew Wilson

 STLSoft moderator and C++ monomaniac       (http://www.stlsoft.org)
 Contributing editor, C/C++ Users Journal
 (www.synesis.com.au/articles.html#columns)

 "If i'm curt with you it's because time is a factor. I think fast, I




 talk

 fast, and I need you guys to act fast" -- Mr Wolf






 --------------------------------------------------------------------------

 --

 ---


 "Patrick Down" <Patrick_member pathlink.com> wrote in message
 news:bn73fk$1jfo$1 digitaldaemon.com...

 In article <bn6tgo$1b4d$1 digitaldaemon.com>, Matthew Wilson










says...

"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:bn6skf$19si$1 digitaldaemon.com...

 In article <bn6sef$19kb$1 digitaldaemon.com>, Matthew Wilson










 says...

I've been thinking about this module naming stuff, and














 considering

 C++'s

approach.

Clearly one of the reasons they chose std was because it was
















at

 least

 a

bit

unambiguous (three letters!)


 HEY!   Why can't we use std?  standard-d?


Well I guess no reason, other than Walter (and others, me












included)

 want

 D.

The main contention is that it seems that Walter's the only one








 (who's

publicly expressed, anyway) the preference for D over d, despite










 the

inconsistency. Do you have a preference in that regard?


 If you held my arm against my back and forced me to make a










decision

 I would say d.   But I really dislike using a one letter name.
Oct 22 2003
parent "Charles Sanders" <sanders-consulting comcast.net> writes:
If it's a library against which one is linking it doesn't matter how much


it

has in it, does it? The linker will take what it needs.


Eeep your right.  Well that was my only real problem with it , so seeing as
its not an issue im for packing it full ( no xml please ;) ).

C


"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bn7ban$1tkg$1 digitaldaemon.com...

 "Charles Sanders" <sanders-consulting comcast.net> wrote in message
 news:bn79m9$1rdq$1 digitaldaemon.com...

 I guess it just invites those NIH instincts to rise


 NIH ?


 Not Invented Here. Apart from a propensity for thinking in binary, this is
 about the most innate aspect of all software engineers.

 Walter wrote his own C++ compiler because he didn't want to use anyone
 else's. Then he wrote his own language because he didn't want to use


anyone

 else's.

 I released STLSoft because one of the Boost's core libraries (no names, no
 pack drill) said something so fundamentally stupid as a justification for


a

 (wrong) implemetation strategy that I just completely lost faith in their
 ability to produce efficient and robust code. (Of course, they have


produced

 a lot of robust code, don't get me wrong, just explaining the instincts.)


 In any case, why is it only platforms that one should be independent






of?

 One

 could equally argue that XML stuff shouldn't be in there.


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


 Do you really want to hold up the C runtime library as an example of






the

 best libraries there can be? Surely not.


 Whats wrong with C library ?


 Well, it's great that its got an ABI, but it gets that from C. There are
 many many bad things about it. People only don't notice because they


compare

 it to the C++ standard libraries (STL, for the most part, excepted)


against

 which it looks orthogonal, efficient and neat.


 But my main argument is not that we shouldn't have the functionality you
 mentioned, I think we defeintly need that but I don't think it should be


 in

 the one library that MUST be linked in.  C's lib is small and effecient,
 thats where I was going with the C refrence.  All those other libs can




be

 implemeneted apart from phobos, so we can choose wether or not we want




to

 link them in ( and make our end executable larger) .


 If it's a library against which one is linking it doesn't matter how much


it

 has in it, does it? The linker will take what it needs. But that's beside
 the point, we should/must have a set of libraries that make sense, and are
 as interdependent as necessary, but no more. That's all still up in the


air,

 and your comments of the previous paragraph are as valid as what anyone


else

 thinks at this time.


 We can make them 'official' in some other respect ?  ( If thats a




problem

 ? )


 I think we're talking at cross purposes here. The standard library


(AFAIUI)

 is what ships with the D compiler as standard, and not necessary what is


in

 a specific .lib, or set of them. That's all still in the air


 C

 "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
 news:bn781a$1pal$1 digitaldaemon.com...

 I vote phobos, its the name of the runtime library why cant other




 vendors

 call it that also ?


 I guess it just invites those NIH instincts to rise. I guess the




 thinking

 is

 it's nice how Java's std libraries are under java, so why can't D have




 the

 same?


 Also, what is win32 / linux specifc stuff doing in the library ?


 Why shouldn't platform specific stuff be in the library? This is a


 language

 about usability and efficiency, not some notional purity. If we want
 everything to be platform/technology independent, we're going to have




 some

 very unweidly and inefficient code, like .. erm .. Java.

 In any case, why is it only platforms that one should be independent o






f?

 One

 could equally argue that XML stuff shouldn't be in there. Or UDP vs






TCP:

 shouldn't it all be an invisible

 Of course no-one's saying that common functionality, like






file-handling,

 should be implemented in a specific fashion, but do you not think






there

 are

 platform-specific features that we would want in?

 Consider the case of COM. Imagine for a moment that COM really had






made

 a

 successful transition to Linux. In this case, when we implement the
 platform-independent D COM libraries we're a bit stuck. The Win32




 versions

 of the D.com modules will have to reference some "external" modules,






in

 order to implement their registration functionality.

 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.



  Shouldn't phobos just contain platform indepenent functions, like








C's

 ?

 Do you really want to hold up the C runtime library as an example of






the

 best libraries there can be? Surely not.


 I pray that D is not selected, although d gets my vote if we cant








have

 phobos.


 Agreed


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

 The primary bifurcation on opinion is whether it is d/D or a




 multi-letter.

 Personally I'm still in two minds about this, although I lean








 towards

 d/D

 Secondary to that, therefore, is whether on for former case we go








 for

 d

 or

 for D. I lean towards d, and think that in either case it's not


 unreasonable

 to reserve the name of the language (in both cases).

 For the case of multi-letter prefixes, phobos is ruled out because








 of

 its

 (Digital) Mars specificity, but the other contenders seem








 reasonable,

 albeit

 somewhat prosaic.

 It would be useful if everyone could express their opinions on the






 main

 question of d/D vs multi-letter, *and* the secondary questions.

 Is there a possibility that one of you web-enabled kinda guys










could

 organise

 a vote? Helmut, what about a place on your wiki stuff?

 Anyway, it may well be that Walter's just decided, and that's it,








 but

 until

 he says he is immovable I would like to explore. This is a very




 important

 issue that, once fixed, cannot be changed, so it's worth a little










of

 all

 our

 consideration.

 Cheers


 -- 
 Matthew Wilson

 STLSoft moderator and C++ monomaniac










(http://www.stlsoft.org)

 Contributing editor, C/C++ Users Journal
 (www.synesis.com.au/articles.html#columns)

 "If i'm curt with you it's because time is a factor. I think fast,










I

 talk

 fast, and I need you guys to act fast" -- Mr Wolf








 --------------------------------------------------------------------------

 --

 ---


 "Patrick Down" <Patrick_member pathlink.com> wrote in message
 news:bn73fk$1jfo$1 digitaldaemon.com...

 In article <bn6tgo$1b4d$1 digitaldaemon.com>, Matthew Wilson










 says...

"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:bn6skf$19si$1 digitaldaemon.com...

 In article <bn6sef$19kb$1 digitaldaemon.com>, Matthew Wilson










 says...

I've been thinking about this module naming stuff, and














 considering

 C++'s

approach.

Clearly one of the reasons they chose std was because it was
















 at

 least

 a

bit

unambiguous (three letters!)


 HEY!   Why can't we use std?  standard-d?


Well I guess no reason, other than Walter (and others, me












 included)

 want

 D.

The main contention is that it seems that Walter's the only one








 (who's

publicly expressed, anyway) the preference for D over d,














despite

 the

inconsistency. Do you have a preference in that regard?


 If you held my arm against my back and forced me to make a










 decision

 I would say d.   But I really dislike using a one letter name.
Oct 22 2003
prev sibling parent "Vathix" <vathix dprogramming.com> writes:
 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.
Oct 23 2003
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bn781a$1pal$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.


  Shouldn't phobos just contain platform indepenent functions, like C's ?


 Do you really want to hold up the C runtime library as an example of the
 best libraries there can be? Surely not.


Nobody said "the best", did they?  But they did some things right.

Sean
Oct 23 2003
parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
 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?
Oct 23 2003
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
"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
Oct 23 2003
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"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.  "platform.win32.*" and
"platform.linux.*".  Maybe also could have "vendor.digitalmars.*" etc for
compiler-specific or vendor-specific functions.

It'd be best to keep the core standard library unpolluted with
platform-specific functions.  Either do least common denominator, emulate
the functionality, or leave it to other libs.

Sean
Oct 23 2003
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
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
Oct 23 2003
parent Jonathan Andrew <s12 kron.cx> writes:
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
Oct 23 2003
prev sibling next sibling parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Also could I get your help on something Matthew if you have time ?

Im using the scintilla MFC wrappers found here : =
http://www.atari-soldiers.com/mfc_scintilla.zip , and Im having trouble =
getting the caret to show up ready for typing when I create new files, =
and also when DIDE loses focus, then regains it.  You have to click on =
the view to be able to edit.

I have tried scintillas methods of :


SetCurrentPos( )
SetSelectionStart( )
GrabFocus()

And also MFC's=20

SetActiveWindow()=20
SetFocus()
SetCaretPos()

I have tried these in an overrided CView::OnActivateView( ... ) function =
, a DisplayErrorFunction, OnInitalUpdate(), OnUpdate() etc... without =
any luck.


Here is a test program Im using =
http://www.atari-soldiers.com/ScintillaTest.zip so you can see it in =
action.

Im stuck on this , dont know what else to try :/.  Thanks for any help!

Charles


"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
=20
 1. D
 2. d
 3. phobos
 4. std
 5. stdd
 6. lang
 7. some other multi-letter prefix
=20
 The primary bifurcation on opinion is whether it is d/D or a =


multi-letter.

 Personally I'm still in two minds about this, although I lean towards =


d/D

=20
 Secondary to that, therefore, is whether on for former case we go for =


d or

 for D. I lean towards d, and think that in either case it's not =


unreasonable

 to reserve the name of the language (in both cases).
=20
 For the case of multi-letter prefixes, phobos is ruled out because of =


its

 (Digital) Mars specificity, but the other contenders seem reasonable, =


albeit

 somewhat prosaic.
=20
 It would be useful if everyone could express their opinions on the =


main

 question of d/D vs multi-letter, *and* the secondary questions.
=20
 Is there a possibility that one of you web-enabled kinda guys could =


organise

 a vote? Helmut, what about a place on your wiki stuff?
=20
 Anyway, it may well be that Walter's just decided, and that's it, but =


until

 he says he is immovable I would like to explore. This is a very =


important

 issue that, once fixed, cannot be changed, so it's worth a little of =


all our

 consideration.
=20
 Cheers
=20
=20
 --=20
 Matthew Wilson
=20
 STLSoft moderator and C++ monomaniac       (http://www.stlsoft.org)
 Contributing editor, C/C++ Users Journal
 (www.synesis.com.au/articles.html#columns)
=20
 "If i'm curt with you it's because time is a factor. I think fast, I =


talk

 fast, and I need you guys to act fast" -- Mr Wolf
=20
 =


-------------------------------------------------------------------------=
---

 ---
=20
=20
 "Patrick Down" <Patrick_member pathlink.com> wrote in message
 news:bn73fk$1jfo$1 digitaldaemon.com...

 In article <bn6tgo$1b4d$1 digitaldaemon.com>, Matthew Wilson says...

"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:bn6skf$19si$1 digitaldaemon.com...

 In article <bn6sef$19kb$1 digitaldaemon.com>, Matthew Wilson =








says...

I've been thinking about this module naming stuff, and =










considering

 C++'s

approach.

Clearly one of the reasons they chose std was because it was at =










least

 a

bit

unambiguous (three letters!)


 HEY!   Why can't we use std?  standard-d?


Well I guess no reason, other than Walter (and others, me included) =






want

 D.

The main contention is that it seems that Walter's the only one =






(who's

publicly expressed, anyway) the preference for D over d, despite =






the

inconsistency. Do you have a preference in that regard?


 If you held my arm against my back and forced me to make a decision
 I would say d.   But I really dislike using a one letter name.


=20
Oct 22 2003
parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Charles

I'd be delighted to help, and maybe I will get time at some random point =
in the next week or so, but it's looking dodgy. I have 90,000 words to =
research and write, and 9 weeks to do it! The publisher's breathing over =
my shoulder is misting up my monitor as it is.

Maybe if you can break down the problem and post bits here I (and =
others) may be able to shed some light, but I can't see me having time =
to download and mess around. I'm really sorry, as I'd very much like to =
support your effort - indeed, I was thinking of giving some help once =
the book's out of the way, maybe we can plug some STLSoft stuff in there =
;).

Matthew

  "Charles Sanders" <sanders-consulting comcast.net> wrote in message =
news:bn77h5$1omu$1 digitaldaemon.com...
  Also could I get your help on something Matthew if you have time ?

  Im using the scintilla MFC wrappers found here : =
http://www.atari-soldiers.com/mfc_scintilla.zip , and Im having trouble =
getting the caret to show up ready for typing when I create new files, =
and also when DIDE loses focus, then regains it.  You have to click on =
the view to be able to edit.

  I have tried scintillas methods of :


  SetCurrentPos( )
  SetSelectionStart( )
  GrabFocus()

  And also MFC's=20

  SetActiveWindow()=20
  SetFocus()
  SetCaretPos()

  I have tried these in an overrided CView::OnActivateView( ... ) =
function , a DisplayErrorFunction, OnInitalUpdate(), OnUpdate() etc... =
without any luck.


  Here is a test program Im using =
http://www.atari-soldiers.com/ScintillaTest.zip so you can see it in =
action.

  Im stuck on this , dont know what else to try :/.  Thanks for any =
help!

  Charles


  "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
  >=20
  > 1. D
  > 2. d
  > 3. phobos
  > 4. std
  > 5. stdd
  > 6. lang
  > 7. some other multi-letter prefix
  >=20
  > The primary bifurcation on opinion is whether it is d/D or a =
multi-letter.
  > Personally I'm still in two minds about this, although I lean =
towards d/D
  >=20
  > Secondary to that, therefore, is whether on for former case we go =
for d or
  > for D. I lean towards d, and think that in either case it's not =
unreasonable
  > to reserve the name of the language (in both cases).
  >=20
  > For the case of multi-letter prefixes, phobos is ruled out because =
of its
  > (Digital) Mars specificity, but the other contenders seem =
reasonable, albeit
  > somewhat prosaic.
  >=20
  > It would be useful if everyone could express their opinions on the =
main
  > question of d/D vs multi-letter, *and* the secondary questions.
  >=20
  > Is there a possibility that one of you web-enabled kinda guys could =
organise
  > a vote? Helmut, what about a place on your wiki stuff?
  >=20
  > Anyway, it may well be that Walter's just decided, and that's it, =
but until
  > he says he is immovable I would like to explore. This is a very =
important
  > issue that, once fixed, cannot be changed, so it's worth a little of =
all our
  > consideration.
  >=20
  > Cheers
  >=20
  >=20
  > --=20
  > Matthew Wilson
  >=20
  > STLSoft moderator and C++ monomaniac       (http://www.stlsoft.org)
  > Contributing editor, C/C++ Users Journal
  > (www.synesis.com.au/articles.html#columns)
  >=20
  > "If i'm curt with you it's because time is a factor. I think fast, I =
talk
  > fast, and I need you guys to act fast" -- Mr Wolf
  >=20
  > =
-------------------------------------------------------------------------=
---
  > ---
  >=20
  >=20
  > "Patrick Down" <Patrick_member pathlink.com> wrote in message
  > news:bn73fk$1jfo$1 digitaldaemon.com...
  > > In article <bn6tgo$1b4d$1 digitaldaemon.com>, Matthew Wilson =
says...
  > > >
  > > >
  > > >"Patrick Down" <Patrick_member pathlink.com> wrote in message
  > > >news:bn6skf$19si$1 digitaldaemon.com...
  > > >> In article <bn6sef$19kb$1 digitaldaemon.com>, Matthew Wilson =
says...
  > > >> >
  > > >> >I've been thinking about this module naming stuff, and =
considering
  > C++'s
  > > >> >approach.
  > > >> >
  > > >> >Clearly one of the reasons they chose std was because it was =
at least
  > a
  > > >bit
  > > >> >unambiguous (three letters!)
  > > >>
  > > >> HEY!   Why can't we use std?  standard-d?
  > > >
  > > >Well I guess no reason, other than Walter (and others, me =
included) want
  > D.
  > > >The main contention is that it seems that Walter's the only one =
(who's
  > > >publicly expressed, anyway) the preference for D over d, despite =
the
  > > >inconsistency. Do you have a preference in that regard?
  > >
  > > If you held my arm against my back and forced me to make a =
decision
  > > I would say d.   But I really dislike using a one letter name.
  > >
  > >
  > >
  >=20
  >
Oct 22 2003
parent "Charles Sanders" <sanders-consulting comcast.net> writes:
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


 The publisher's breathing over my shoulder is misting up my monitor as =


it is.

Ahh finnaly found the title 'Imperfect C++' in this month's CUJ :) =20


 maybe we can plug some STLSoft stuff in there ;).


Defintly I keep meaning to but time is so scarce :/.  Ill try to post =
snippets as I go along=20

Thx,
C
  "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message =
news:bn7893$1pid$1 digitaldaemon.com...
  Charles

  I'd be delighted to help, and maybe I will get time at some random =
point in the next week or so, but it's looking dodgy. I have 90,000 =
words to research and write, and 9 weeks to do it! The publisher's =
breathing over my shoulder is misting up my monitor as it is.

  Maybe if you can break down the problem and post bits here I (and =
others) may be able to shed some light, but I can't see me having time =
to download and mess around. I'm really sorry, as I'd very much like to =
support your effort - indeed, I was thinking of giving some help once =
the book's out of the way, maybe we can plug some STLSoft stuff in there =
;).

  Matthew

    "Charles Sanders" <sanders-consulting comcast.net> wrote in message =
news:bn77h5$1omu$1 digitaldaemon.com...
    Also could I get your help on something Matthew if you have time ?

    Im using the scintilla MFC wrappers found here : =
http://www.atari-soldiers.com/mfc_scintilla.zip , and Im having trouble =
getting the caret to show up ready for typing when I create new files, =
and also when DIDE loses focus, then regains it.  You have to click on =
the view to be able to edit.

    I have tried scintillas methods of :


    SetCurrentPos( )
    SetSelectionStart( )
    GrabFocus()

    And also MFC's=20

    SetActiveWindow()=20
    SetFocus()
    SetCaretPos()

    I have tried these in an overrided CView::OnActivateView( ... ) =
function , a DisplayErrorFunction, OnInitalUpdate(), OnUpdate() etc... =
without any luck.


    Here is a test program Im using =
http://www.atari-soldiers.com/ScintillaTest.zip so you can see it in =
action.

    Im stuck on this , dont know what else to try :/.  Thanks for any =
help!

    Charles


    "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
    >=20
    > 1. D
    > 2. d
    > 3. phobos
    > 4. std
    > 5. stdd
    > 6. lang
    > 7. some other multi-letter prefix
    >=20
    > The primary bifurcation on opinion is whether it is d/D or a =
multi-letter.
    > Personally I'm still in two minds about this, although I lean =
towards d/D
    >=20
    > Secondary to that, therefore, is whether on for former case we go =
for d or
    > for D. I lean towards d, and think that in either case it's not =
unreasonable
    > to reserve the name of the language (in both cases).
    >=20
    > For the case of multi-letter prefixes, phobos is ruled out because =
of its
    > (Digital) Mars specificity, but the other contenders seem =
reasonable, albeit
    > somewhat prosaic.
    >=20
    > It would be useful if everyone could express their opinions on the =
main
    > question of d/D vs multi-letter, *and* the secondary questions.
    >=20
    > Is there a possibility that one of you web-enabled kinda guys =
could organise
    > a vote? Helmut, what about a place on your wiki stuff?
    >=20
    > Anyway, it may well be that Walter's just decided, and that's it, =
but until
    > he says he is immovable I would like to explore. This is a very =
important
    > issue that, once fixed, cannot be changed, so it's worth a little =
of all our
    > consideration.
    >=20
    > Cheers
    >=20
    >=20
    > --=20
    > Matthew Wilson
    >=20
    > STLSoft moderator and C++ monomaniac       =
(http://www.stlsoft.org)
    > Contributing editor, C/C++ Users Journal
    > (www.synesis.com.au/articles.html#columns)
    >=20
    > "If i'm curt with you it's because time is a factor. I think fast, =
I talk
    > fast, and I need you guys to act fast" -- Mr Wolf
    >=20
    > =
-------------------------------------------------------------------------=
---
    > ---
    >=20
    >=20
    > "Patrick Down" <Patrick_member pathlink.com> wrote in message
    > news:bn73fk$1jfo$1 digitaldaemon.com...
    > > In article <bn6tgo$1b4d$1 digitaldaemon.com>, Matthew Wilson =
says...
    > > >
    > > >
    > > >"Patrick Down" <Patrick_member pathlink.com> wrote in message
    > > >news:bn6skf$19si$1 digitaldaemon.com...
    > > >> In article <bn6sef$19kb$1 digitaldaemon.com>, Matthew Wilson =
says...
    > > >> >
    > > >> >I've been thinking about this module naming stuff, and =
considering
    > C++'s
    > > >> >approach.
    > > >> >
    > > >> >Clearly one of the reasons they chose std was because it was =
at least
    > a
    > > >bit
    > > >> >unambiguous (three letters!)
    > > >>
    > > >> HEY!   Why can't we use std?  standard-d?
    > > >
    > > >Well I guess no reason, other than Walter (and others, me =
included) want
    > D.
    > > >The main contention is that it seems that Walter's the only one =
(who's
    > > >publicly expressed, anyway) the preference for D over d, =
despite the
    > > >inconsistency. Do you have a preference in that regard?
    > >
    > > If you held my arm against my back and forced me to make a =
decision
    > > I would say d.   But I really dislike using a one letter name.
    > >
    > >
    > >
    >=20
    >
Oct 22 2003
prev sibling next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
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. dee
8. drt (D RunTime)
9. dlib


 [10]. some other multi-letter prefix



D/d:
I don't think it's to anyone's benefit to turn all the individual 
letters into potential minefields (hey, we could also rename "if" to "i" 
and "for" to "f").  If we have to go this route, I prefer using "d" for 
the module prefix for the sake of having a consistent module naming 
convention.


 
 The primary bifurcation on opinion is whether it is d/D or a multi-letter.
 Personally I'm still in two minds about this, although I lean towards d/D
 
 Secondary to that, therefore, is whether on for former case we go for d or
 for D. I lean towards d, and think that in either case it's not unreasonable
 to reserve the name of the language (in both cases).
 
 For the case of multi-letter prefixes, phobos is ruled out because of its
 (Digital) Mars specificity, but the other contenders seem reasonable, albeit
 somewhat prosaic.
 


I think phobos is an interesting, distinctive name.  Don't we want it to 
be an interesting, distinctive library?


 It would be useful if everyone could express their opinions on the main
 question of d/D vs multi-letter, *and* the secondary questions.
 
 Is there a possibility that one of you web-enabled kinda guys could organise
 a vote? Helmut, what about a place on your wiki stuff?
 
 Anyway, it may well be that Walter's just decided, and that's it, but until
 he says he is immovable I would like to explore. This is a very important
 issue that, once fixed, cannot be changed, so it's worth a little of all our
 consideration.
 
 Cheers


Justin
Oct 22 2003
next sibling parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
"J C Calvarese" <jcc7 cox.net> wrote in message
news:bn79ud$1rmr$1 digitaldaemon.com...

 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. dee
 8. drt (D RunTime)
 9. dlib

  > [10]. some other multi-letter prefix


 D/d:
 I don't think it's to anyone's benefit to turn all the individual
 letters into potential minefields (hey, we could also rename "if" to "i"
 and "for" to "f").


You're over egging your pudding here. No one's suggested doing this.

(It's not politics; there's no need to invent counter arguments to rail
against. ;)


 If we have to go this route, I prefer using "d" for
 the module prefix for the sake of having a consistent module naming
 convention.


Noted. Another one in the lowercase camp.


 The primary bifurcation on opinion is whether it is d/D or a




multi-letter.

 Personally I'm still in two minds about this, although I lean towards




d/D

 Secondary to that, therefore, is whether on for former case we go for d




or

 for D. I lean towards d, and think that in either case it's not




unreasonable

 to reserve the name of the language (in both cases).

 For the case of multi-letter prefixes, phobos is ruled out because of




its

 (Digital) Mars specificity, but the other contenders seem reasonable,




albeit

 somewhat prosaic.


 I think phobos is an interesting, distinctive name.  Don't we want it to
 be an interesting, distinctive library?


We do. It's not me who's having the strong objections to Phobos - IIRC
that's Walter himself - but I can see it does make the language, or the
library at least, look a little toy/juvenile. But it's not a strong
impression.


 It would be useful if everyone could express their opinions on the main
 question of d/D vs multi-letter, *and* the secondary questions.

 Is there a possibility that one of you web-enabled kinda guys could




organise

 a vote? Helmut, what about a place on your wiki stuff?

 Anyway, it may well be that Walter's just decided, and that's it, but




until

 he says he is immovable I would like to explore. This is a very




important

 issue that, once fixed, cannot be changed, so it's worth a little of all




our

 consideration.

 Cheers


 Justin
Oct 22 2003
parent reply J C Calvarese <jcc7 cox.net> writes:
Matthew Wilson wrote:


 "J C Calvarese" <jcc7 cox.net> wrote in message


...


D/d:
I don't think it's to anyone's benefit to turn all the individual
letters into potential minefields (hey, we could also rename "if" to "i"
and "for" to "f").


 
 
 You're over egging your pudding here. No one's suggested doing this.
 
 (It's not politics; there's no need to invent counter arguments to rail
 against. ;) 


I think this might have made more sense if I had typed out more of what 
I was thinking.

I was just trying to mention that there's probably a reason why we don't 
have any one-letter keywords -- being that terse when creating a 
language is a recipe for disaster.  I don't think it's too much to ask 
that a top-level package have at least a couple of letters in it.

My point was I think there's an implicit line drawn on how short a 
keyword can be, and I think we need to have expectations on how short a 
package name should be.

A while back I was working on a small project and suddenly these strange 
compile errors started popping up regarding a variable that seemed to 
work fine before (it happened to be named "c").  Then I realized the 
problem came from when I added "import c.something" to either that file 
or something that was imported by that file.  I didn't know it would 
cause a problem to use a variable named "c".  That name had been fair 
game before and now suddenly it was off-limits.  D will be more 
successful if newbies have fewer random brick walls to run into.

Okay, I've rambled enough at this point...

Justin
Oct 22 2003
parent "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
It's a fair point. But the neatness of d.xyz.abc is going to be hard to
fight.


"J C Calvarese" <jcc7 cox.net> wrote in message
news:bn7e9k$21dq$1 digitaldaemon.com...

 Matthew Wilson wrote:


 "J C Calvarese" <jcc7 cox.net> wrote in message


 ...


D/d:
I don't think it's to anyone's benefit to turn all the individual
letters into potential minefields (hey, we could also rename "if" to "i"
and "for" to "f").



 You're over egging your pudding here. No one's suggested doing this.

 (It's not politics; there's no need to invent counter arguments to rail
 against. ;)


 I think this might have made more sense if I had typed out more of what
 I was thinking.

 I was just trying to mention that there's probably a reason why we don't
 have any one-letter keywords -- being that terse when creating a
 language is a recipe for disaster.  I don't think it's too much to ask
 that a top-level package have at least a couple of letters in it.

 My point was I think there's an implicit line drawn on how short a
 keyword can be, and I think we need to have expectations on how short a
 package name should be.

 A while back I was working on a small project and suddenly these strange
 compile errors started popping up regarding a variable that seemed to
 work fine before (it happened to be named "c").  Then I realized the
 problem came from when I added "import c.something" to either that file
 or something that was imported by that file.  I didn't know it would
 cause a problem to use a variable named "c".  That name had been fair
 game before and now suddenly it was off-limits.  D will be more
 successful if newbies have fewer random brick walls to run into.

 Okay, I've rambled enough at this point...

 Justin
Oct 22 2003
prev sibling next sibling parent reply Patrick Down <pat codemoon.com> writes:
J C Calvarese <jcc7 cox.net> wrote in
news:bn79ud$1rmr$1 digitaldaemon.com: 


 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. dee
 8. drt (D RunTime)
 9. dlib


10. dsl ( D standard library )
Oct 22 2003
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
Great minds think alike.  ;)

Sean

"Patrick Down" <pat codemoon.com> wrote in message
news:Xns941CDE50916BApatcodemooncom 63.105.9.61...

 10. dsl ( D standard library )
Oct 23 2003
prev sibling next sibling parent "Charles Sanders" <sanders-consulting comcast.net> writes:
Ok i change my vote to drt.

C


"J C Calvarese" <jcc7 cox.net> wrote in message
news:bn79ud$1rmr$1 digitaldaemon.com...

 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. dee
 8. drt (D RunTime)
 9. dlib

  > [10]. some other multi-letter prefix


 D/d:
 I don't think it's to anyone's benefit to turn all the individual
 letters into potential minefields (hey, we could also rename "if" to "i"
 and "for" to "f").  If we have to go this route, I prefer using "d" for
 the module prefix for the sake of having a consistent module naming
 convention.


 The primary bifurcation on opinion is whether it is d/D or a




multi-letter.

 Personally I'm still in two minds about this, although I lean towards




d/D

 Secondary to that, therefore, is whether on for former case we go for d




or

 for D. I lean towards d, and think that in either case it's not




unreasonable

 to reserve the name of the language (in both cases).

 For the case of multi-letter prefixes, phobos is ruled out because of




its

 (Digital) Mars specificity, but the other contenders seem reasonable,




albeit

 somewhat prosaic.


 I think phobos is an interesting, distinctive name.  Don't we want it to
 be an interesting, distinctive library?


 It would be useful if everyone could express their opinions on the main
 question of d/D vs multi-letter, *and* the secondary questions.

 Is there a possibility that one of you web-enabled kinda guys could




organise

 a vote? Helmut, what about a place on your wiki stuff?

 Anyway, it may well be that Walter's just decided, and that's it, but




until

 he says he is immovable I would like to explore. This is a very




important

 issue that, once fixed, cannot be changed, so it's worth a little of all




our

 consideration.

 Cheers


 Justin
Oct 22 2003
prev sibling parent reply Helmut Leitner <helmut.leitner chello.at> writes:
J C Calvarese wrote:

 
 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. dee
 8. drt (D RunTime)
 9. dlib            <====


That's my favorite, because that's what it is, 
the "D library", in short.

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
Oct 22 2003
parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
But its a contraction, rather than an initialism. Why not dli? or dlibr? See
what I mean?

I'd rather dsl, for D standard library, than that, but I'd rather just "d"

"Helmut Leitner" <helmut.leitner chello.at> wrote in message
news:3F976C76.5BCF6E5C chello.at...

 J C Calvarese wrote:

 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. dee
 8. drt (D RunTime)
 9. dlib            <====


 That's my favorite, because that's what it is,
 the "D library", in short.

 -- 
 Helmut Leitner    leitner hls.via.at
 Graz, Austria   www.hls-software.com
Oct 23 2003
next sibling parent "Rupert Millard" <rupertamillard hotmail.DELETE.THIS.com> writes:
Matthew,

I take your point about contractions in general, but I think lib is so
ubiquitous in other languages it has become engrained in programmers minds
as meaning library.

My first choice is "dlib," with the C library called "clib."
My second choice would be "dsl," with the C library called "csl."
My third choice is an uppercase "D", with the C library called "C."

I think the single lowercase character "d" is asking for trouble. I don't
think this will prevent compilation, but dlib itself ;-) uses variables
called "d" in places (date.d, math.d, math2.d, path.d). It would seem very
arbitrary to me if I saw a line of code like "int a, b, c, e, f" and I think
it would flummox beginners to find that you have to do this.

From,

Rupert

"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bn7ujf$2nij$1 digitaldaemon.com...

 But its a contraction, rather than an initialism. Why not dli? or dlibr?


See

 what I mean?

 I'd rather dsl, for D standard library, than that, but I'd rather just "d"

 "Helmut Leitner" <helmut.leitner chello.at> wrote in message
 news:3F976C76.5BCF6E5C chello.at...

 J C Calvarese wrote:

 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. dee
 8. drt (D RunTime)
 9. dlib            <====


 That's my favorite, because that's what it is,
 the "D library", in short.

 --
 Helmut Leitner    leitner hls.via.at
 Graz, Austria   www.hls-software.com
Oct 23 2003
prev sibling parent reply Helmut Leitner <leitner hls.via.at> writes:
 9. dlib            <====


 That's my favorite, because that's what it is,
 the "D library", in short.




Matthew Wilson wrote:

 
 But its a contraction, rather than an initialism. Why not dli? or dlibr? See
 what I mean?


No, there are two ways to argue for "dlib".

First "lib" is the typical library file extension / abbreviation,
so its the shortest way to get all the semantics in.

Second, just test programmer expectations. Ask ten people which
abbreviation feels most natural for "D libary" and offer them 
your choices, for example
  
   - dli
   - dlib
   - dlibr
   - std 
   - stl

or whatever you like. Make them use the name in sentences
like
   "Where can I download the new ... version?" 
   "Is this a ... module?"
   "Is there an online ... reference?"
   "Is ... covered in the book 'D programming'?"
before they make their decision. 
What is easiest to talk about? 
What feels most natural?
Don't let them make quick decisions. Let them think about it,
ask them for their final decision after a day.

Then follow the majority of programmer expectations,
they will be right. I'm pretty sure that at least 7/10
will vote for "dlib" and no other choice will get more
that 2 votes.

Anyway it seems quite clear to me, that neither "d" nor "D"
are valid choices. Because
   "Where can I download the new D version?" 
   "Is this a D module?"
   "Is there an online D reference?"
   "Is D covered in the book 'D programming'?"
doesn't clearly refer to the library. 
You would always have to talk around it, like 
   "Is the D-library covered in the book 'D programming'?".
Here again comes "dlib" as the most natural abbreviation.

Of course "dlibrary" would also be good, but I know that Walter
would never, never, never accept such a long name.

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
Oct 23 2003
parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
"Helmut Leitner" <leitner hls.via.at> wrote in message
news:3F978DCF.8218ED54 hls.via.at...

 9. dlib            <====


 That's my favorite, because that's what it is,
 the "D library", in short.




 Matthew Wilson wrote:

 But its a contraction, rather than an initialism. Why not dli? or dlibr?




See

 what I mean?


 No, there are two ways to argue for "dlib".

 First "lib" is the typical library file extension / abbreviation,
 so its the shortest way to get all the semantics in.

 Second, just test programmer expectations. Ask ten people which
 abbreviation feels most natural for "D libary" and offer them
 your choices, for example


Well, I was using reductio ad absurdum, so was not suggesting dli or dlibr
as they are both unambiguously offensive. ;)


    - dli
    - dlib
    - dlibr
    - std
    - stl

 or whatever you like. Make them use the name in sentences
 like
    "Where can I download the new ... version?"
    "Is this a ... module?"
    "Is there an online ... reference?"
    "Is ... covered in the book 'D programming'?"
 before they make their decision.
 What is easiest to talk about?
 What feels most natural?
 Don't let them make quick decisions. Let them think about it,
 ask them for their final decision after a day.

 Then follow the majority of programmer expectations,
 they will be right. I'm pretty sure that at least 7/10
 will vote for "dlib" and no other choice will get more
 that 2 votes.


I just hate dlib. zlib, xmllib, etc. are all specific libraries. dlib just
stands out. Yes, I know libc is the C std lib on UNIX.


 Anyway it seems quite clear to me, that neither "d" nor "D"
 are valid choices. Because
    "Where can I download the new D version?"
    "Is this a D module?"
    "Is there an online D reference?"
    "Is D covered in the book 'D programming'?"
 doesn't clearly refer to the library.
 You would always have to talk around it, like
    "Is the D-library covered in the book 'D programming'?".
 Here again comes "dlib" as the most natural abbreviation.


The d/D.* libraries we are talking about are not just standard libraries of
D, it/they also contain(s) aspects of the language itself, in the same way
that the C runtime library, the C++ standard library do, and the basic Java
libraries do. Hence, your characterisation is somewhat flawed.

Maybe what's been bandied about as the standard library should be explicitly
segregated into language core and libraries, although we may find that's not
as easy to do as it sounds.

Gah! It's all so inconsistent.

I'm afraid that I still think the language is called D, so the module should
be d, just as with Java/java. Sorry. It still seems a minor imposition to
prevent people using d and D as identifiers in a language called D.


 Of course "dlibrary" would also be good, but I know that Walter
 would never, never, never accept such a long name.


Maybe we should get him to change the language name back to mars, and use
that. :)
Oct 23 2003
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bn831f$2u7f$1 digitaldaemon.com...

 Then follow the majority of programmer expectations,
 they will be right. I'm pretty sure that at least 7/10
 will vote for "dlib" and no other choice will get more
 that 2 votes.


 I just hate dlib. zlib, xmllib, etc. are all specific libraries. dlib just
 stands out. Yes, I know libc is the C std lib on UNIX.


You're right... it seems there's precedent for calling it "libd".


 I'm afraid that I still think the language is called D, so the module


should

 be d, just as with Java/java. Sorry. It still seems a minor imposition to
 prevent people using d and D as identifiers in a language called D.


I would hate to lose d and D as identifiers.  Well they wouldn't be lost, as
you can do .d.win32.registry, but they would be a rather common source of
confusion.


 Maybe we should get him to change the language name back to mars, and use
 that. :)


Then we could leave the library named phobos, at least.  ;)

Sean
Oct 23 2003
prev sibling next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
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
Oct 23 2003
parent Felix <Felix_member pathlink.com> writes:
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
Oct 23 2003
prev sibling next sibling parent "Julio César Carrascal Urquijo" <adnoctum phreaker.net> writes:
 1. D
 2. d
 3. phobos
 4. std
 5. stdd
 6. lang
 7. some other multi-letter prefix


My vote would be on "lang".
Oct 23 2003
prev sibling parent Andy Friesen <andy ikagames.com> writes:
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
Oct 23 2003
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bn6sef$19kb$1 digitaldaemon.com...

 btw, can you explain what a C module is? Is this a c library with function
 declarations only in D?


I see it as the thinnest veneer possible over standard C functions, such as
C.stdio, C.stdlib, etc. C modules would follow C conventions, would make no
attempt to convert errno to exceptions, would not attempt to 'clean it up',
etc.

One example of this I ran into with zlib. Zlib has a lot of C style
functionality and behavior. It's not really the D way. So I am putting
together a C.zlib with all that, and then building a D.zlib with it redone
with an easy to use D look and feel.
Oct 22 2003
parent "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
So we could do the same with recls?

:)

"Walter" <walter digitalmars.com> wrote in message
news:bn79f8$1r4i$1 digitaldaemon.com...

 "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
 news:bn6sef$19kb$1 digitaldaemon.com...

 btw, can you explain what a C module is? Is this a c library with




function

 declarations only in D?


 I see it as the thinnest veneer possible over standard C functions, such


as

 C.stdio, C.stdlib, etc. C modules would follow C conventions, would make


no

 attempt to convert errno to exceptions, would not attempt to 'clean it


up',

 etc.

 One example of this I ran into with zlib. Zlib has a lot of C style
 functionality and behavior. It's not really the D way. So I am putting
 together a C.zlib with all that, and then building a D.zlib with it redone
 with an easy to use D look and feel.
Oct 22 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bn6sef$19kb$1 digitaldaemon.com...

 I've been thinking about this module naming stuff, and considering C++'s
 approach.

 Clearly one of the reasons they chose std was because it was at least a


bit

 unambiguous (three letters!)

 I'm starting to wonder whether Helmut's notion of the standard library's
 having something longer than D (or d) makes sense.

 Separately, I still don't see any difference between D and d, other than D
 is less consistent, which will be a permanent flaw on the language. Having
 people not be able to write d in a language called D doesn't seen a great
 hardship. It's not exactly difficult to do a global whole-word search and
 replace to change all d or D into d_ and D_ (or whatever).

 I know I'm wandering a bit, but *please* let us have d.win32.etc.


It isn't cast in stone. All I've really done so far is name D.win32.registry
for your registry package. Let's wait and see a bit and the smoke may clear
on the best solution.
Oct 22 2003
parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
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?

"Walter" <walter digitalmars.com> wrote in message
news:bn79f8$1r4i$2 digitaldaemon.com...

 "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
 news:bn6sef$19kb$1 digitaldaemon.com...

 I've been thinking about this module naming stuff, and considering C++'s
 approach.

 Clearly one of the reasons they chose std was because it was at least a


 bit

 unambiguous (three letters!)

 I'm starting to wonder whether Helmut's notion of the standard library's
 having something longer than D (or d) makes sense.

 Separately, I still don't see any difference between D and d, other than




D

 is less consistent, which will be a permanent flaw on the language.




Having

 people not be able to write d in a language called D doesn't seen a




great

 hardship. It's not exactly difficult to do a global whole-word search




and

 replace to change all d or D into d_ and D_ (or whatever).

 I know I'm wandering a bit, but *please* let us have d.win32.etc.


 It isn't cast in stone. All I've really done so far is name


D.win32.registry

 for your registry package. Let's wait and see a bit and the smoke may


clear

 on the best solution.
Oct 22 2003
next sibling parent reply Ilya Minkov <midiclub tiscali.de> writes:
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?
Oct 23 2003
parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
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?
Oct 23 2003
parent reply Felix <Felix_member pathlink.com> writes:
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?
Oct 23 2003
next sibling parent reply "Julio César Carrascal Urquijo" <adnoctum phreaker.net> writes:
 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?
Oct 23 2003
next sibling parent "Vathix" <vathix dprogramming.com> writes:
"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.
Oct 23 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
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?
Oct 24 2003
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"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
Oct 23 2003
parent reply "Walter" <walter digitalmars.com> writes:
"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>.
Oct 24 2003
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
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>.
Oct 25 2003
prev sibling parent reply "Lars Ivar Igesund" <larsivi stud.ntnu.no> writes:
"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
Oct 23 2003
parent Jonathan Andrew <s12 kron.cx> writes:
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
Oct 23 2003
prev sibling parent reply J C Calvarese <jcc7 cox.net> writes:
Walter wrote:

 "Lars Ivar Igesund" <larsivi stud.ntnu.no> wrote in message
 news:bn5gi1$2f17$1 digitaldaemon.com...
 

Is the phobos docs updated recently? I can't find
D.win32.registry anywhere (on the website). Also,
what works?


 
 
 I'll go with Matthew's answer!
 
 

Can everything have D in front of it? What about d?
What about nothing? In short: What are our choices
when importing something from phobos?


 
 
 Eventually, the packages will look like:
 
 D.???    modules that are available for all D implementations
 D.win32.???   modules that only work on win32
 D.linux.???    modules that only work on linux
 C.???    modules that come from C
 
 


I know this is revolutionary but how about...

phobos.???        modules that are available for all D implementations
phobos.win32.???  modules that only work on win32
phobos.linux.???  modules that only work on linux
phobos.c.???      modules that come from C


Justin
Oct 22 2003
parent "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
The argument against this was that phobos pertains to (Digital) Mars, and
will seem anachronistic and vain when D gains broader implementation by
other vendors.

"J C Calvarese" <jcc7 cox.net> wrote in message
news:bn6v6d$1djh$1 digitaldaemon.com...

 Walter wrote:

 "Lars Ivar Igesund" <larsivi stud.ntnu.no> wrote in message
 news:bn5gi1$2f17$1 digitaldaemon.com...


Is the phobos docs updated recently? I can't find
D.win32.registry anywhere (on the website). Also,
what works?



 I'll go with Matthew's answer!



Can everything have D in front of it? What about d?
What about nothing? In short: What are our choices
when importing something from phobos?



 Eventually, the packages will look like:

 D.???    modules that are available for all D implementations
 D.win32.???   modules that only work on win32
 D.linux.???    modules that only work on linux
 C.???    modules that come from C


 I know this is revolutionary but how about...

 phobos.???        modules that are available for all D implementations
 phobos.win32.???  modules that only work on win32
 phobos.linux.???  modules that only work on linux
 phobos.c.???      modules that come from C


 Justin
Oct 22 2003
prev sibling parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
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
Oct 23 2003
parent Patrick Down <pat codemoon.com> writes:
"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
Oct 23 2003