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


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


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




approach.

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




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


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

 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,

 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

 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

 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

 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




approach.

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





 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)



 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


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


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


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

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

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


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

 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

 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

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


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

 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


 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





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




approach.

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





 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)



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




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

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

 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


 call it that also ?

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

 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

 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?

 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

 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

 Linux version is pretty slim (although maybe that's not the case for

 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


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


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



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

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

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


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

 somewhat prosaic.

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



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

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

 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

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


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



 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


 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





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







 C++'s
approach.

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





 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)



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




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





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


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?

 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

 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


 call it that also ?

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


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


 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

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


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

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

 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

 platform-specific features that we would want in?

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


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


 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


 a
 Linux version is pretty slim (although maybe that's not the case for

 but I'm sure you can extrapolate to other things. Networking, for


 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


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




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




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

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

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




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




 albeit
 somewhat prosaic.

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



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

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

 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,




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


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



 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


 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





"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:bn6skf$19si$1 digitaldaemon.com...
 In article <bn6sef$19kb$1 digitaldaemon.com>, Matthew Wilson





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







 C++'s
approach.

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








 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






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




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





inconsistency. Do you have a preference in that regard?

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





 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

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


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

 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

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

 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



 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



 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

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

 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

 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


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


 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

 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

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

 thinks at this time.

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


 ? )

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

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

 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


 call it that also ?

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


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


 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

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


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

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



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



 shouldn't it all be an invisible

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



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



 are
 platform-specific features that we would want in?

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



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


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



 order to implement their registration functionality.

 Now maybe COM is not the best example, because the likelihood of our


 a
 Linux version is pretty slim (although maybe that's not the case for

 but I'm sure you can extrapolate to other things. Networking, for


 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




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



 best libraries there can be? Surely not.

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




 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


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




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




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

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

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




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




 albeit
 somewhat prosaic.

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



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

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





 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,




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


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





 all
 our
 consideration.

 Cheers


 -- 
 Matthew Wilson

 STLSoft moderator and C++ monomaniac





 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,





 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





"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:bn6skf$19si$1 digitaldaemon.com...
 In article <bn6sef$19kb$1 digitaldaemon.com>, Matthew Wilson





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







 C++'s
approach.

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








 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






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




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







 the
inconsistency. Do you have a preference in that regard?

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





 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

 Linux version is pretty slim (although maybe that's not the case for

 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


 a
 Linux version is pretty slim (although maybe that's not the case for

 but I'm sure you can extrapolate to other things. Networking, for


 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


 a
 Linux version is pretty slim (although maybe that's not the case for

 but I'm sure you can extrapolate to other things. Networking, for


 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


 the hood.

But what if those under-the-hood things are also to be provided as

 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 ?

 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:
Content-Type: text/plain;
	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 =

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

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

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

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

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

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

 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 =

 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 =

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

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

 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 =

 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 =




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





 C++'s
approach.

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





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



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



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



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:
Content-Type: text/plain;
	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:
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

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


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


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


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


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

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


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


 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


 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


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


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


 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


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


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


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


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

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


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


 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


 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


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


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


 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?

 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?


 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

 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


 declarations only in D?

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

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

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

 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

 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

 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


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


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


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


 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

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

 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,


 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,


 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

 syntax... It is sometimes useful. The default should be a "public" import

 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

 syntax... It is sometimes useful. The default should be a "public"


 (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

 syntax... It is sometimes useful. The default should be a "public"


 (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

 syntax... It is sometimes useful. The default should be a "public" import

 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.

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.

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