www.digitalmars.com         C & C++   DMDScript  

D - importing rule

reply "Y.Tomino" <demoonlit inter7.jp> writes:
Hello.

I think we should use "private import" instead of "(public) import" for
platform modules.
"private import" can avoid conflicting identifiers, and high-level or
cross-platform libraries should not show low-level platform modules it used.

DMD staff, please use "private import" in phobos.
thread.d, file.d, stream.d, etc. look unrelated to Windows, but these
"public import" phobos's windows.d (or linux.d).
That makes it difficult beyond necessity for us to use another windows
module.

Thanks.
YT
Oct 27 2003
next sibling parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
Guys

I confess I have so far digested virtually nothing of the import rules, but
have picked up from the ng that there are problems.

Is anyone in a position to give a 2-3 paragraph of the current mechanism, to
which the rest can then post the problems, as they see them? I'm sure I'm
not the only one who would benefit from this.

YT's suggestion sounds sensible, but I just don't have enough experience
with the importing issues to comment authoritatively.




"Y.Tomino" <demoonlit inter7.jp> wrote in message
news:bnjtv0$7g2$1 digitaldaemon.com...
 Hello.

 I think we should use "private import" instead of "(public) import" for
 platform modules.
 "private import" can avoid conflicting identifiers, and high-level or
 cross-platform libraries should not show low-level platform modules it

 DMD staff, please use "private import" in phobos.
 thread.d, file.d, stream.d, etc. look unrelated to Windows, but these
 "public import" phobos's windows.d (or linux.d).
 That makes it difficult beyond necessity for us to use another windows
 module.

 Thanks.
 YT

Oct 27 2003
next sibling parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
We need to stop talking about getting a phobos library group and just do it!

In that spirit I've nominated myself and Lars ( and whoever else is
interested ).  Ill change the imports to private and upload to
www.atari-soldiers.com/phobos.html .

Lars would you be ok with this ?

C


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

 I confess I have so far digested virtually nothing of the import rules,

 have picked up from the ng that there are problems.

 Is anyone in a position to give a 2-3 paragraph of the current mechanism,

 which the rest can then post the problems, as they see them? I'm sure I'm
 not the only one who would benefit from this.

 YT's suggestion sounds sensible, but I just don't have enough experience
 with the importing issues to comment authoritatively.




 "Y.Tomino" <demoonlit inter7.jp> wrote in message
 news:bnjtv0$7g2$1 digitaldaemon.com...
 Hello.

 I think we should use "private import" instead of "(public) import" for
 platform modules.
 "private import" can avoid conflicting identifiers, and high-level or
 cross-platform libraries should not show low-level platform modules it

 DMD staff, please use "private import" in phobos.
 thread.d, file.d, stream.d, etc. look unrelated to Windows, but these
 "public import" phobos's windows.d (or linux.d).
 That makes it difficult beyond necessity for us to use another windows
 module.

 Thanks.
 YT


Oct 27 2003
parent reply "Lars Ivar Igesund" <larsivi stud.ntnu.no> writes:
"Charles Sanders" <sanders-consulting comcast.net> wrote in message
news:bnk4s1$hof$1 digitaldaemon.com...
 We need to stop talking about getting a phobos library group and just do

 In that spirit I've nominated myself and Lars ( and whoever else is
 interested ).  Ill change the imports to private and upload to
 www.atari-soldiers.com/phobos.html .

 Lars would you be ok with this ?

 C

I am flattered that you have so much confidence in what I'm able/willing to use my spare time for :) At the moment, the things I do, I do mostly because they deep down fullfill some personal need. If they also benefit others; great! Now, over to phobos. Are you planning a group that maintains a version of phobos (or the D runtime/standard library)? More or less a fork of the version shipped with DMD? If more people agree with this way of doing things, then I guess that patches could be sent to Walter for inclusion in the official phobos library. He would then only have the easy job of saying yes or no to applying it. If for some reason, this don't happen we would have a situation where "our" phobos would quickly be differentiated from the official version, and they might become incompatible, a much worse situation than today's. I would suggest that Walter nominates members to this group (I'm fairly against selfnomination), perhaps based on applications/election programs :) Walter should himself be a member of the group. Then he should give a mandate to the group. Maybe to be some sort of D library standards body. The library should then be set up as it's own project in a version management system somewhere. And yes, the decision process should be completely open, that is all discussions in this body should be available to those outside of it to read. If this wasn't anywhere close to what you were thinking, then I have at least given my opinion on how the development of the D std lib should be executed :) As to the imports; I vote for having them private as suggested by Y.T. Lars Ivar Igesund
Oct 28 2003
next sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
Walter's page (still) claims Phobos to be inadequate. Besides, i believe 
"Phobos" sounds much like a project name, which could imply that it 
would be called differently in a final version. And be different.

So, we could form a workgroup to make an experimantal base library. Name 
it something different. I guess it should be largly compatible to 
current Phobos, and we'll see to what extent it would prove itself to be 
included in D or not. I propose "altbase" as namespace for it. Anyway, 
changing the namespace is not much of a trouble for porting code, so we 
can decide later how the final library is called, and what library would 
be to what extend be promoted to it. Both original libraries could also 
stay in their prior namespaces for compatibility purposes.

The group should definately have some "head", responsible for library 
design decisions, as well as giving away rights to modify the code 
directly. Though Walter is the ultimate authority, i suggest we get 
someone else executive (Mathew? Burton? Charles?), so that Walter has 
his hands free for working on compilers if he wishes so. He dicides what 
finally gets into the compiler distro, after all. I believe the group 
should work publically - possibly another newsgroup?

|  |  |  |  |
V  V  V  V  V

As to the imports; I vote for having them private as suggested
 by Y.T.

I second that. -eye
Oct 28 2003
prev sibling parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
 our" phobos would quickly be differentiated from
 the official version, and they might become incompatible, a much worse
 situation than today's.

Yes I agree this would get ugly quick. A Phobos library group has been talked about alot but no-one has the time or the "want" to participate, but I agree with Ilya said if we get a standard group we can let Walter focus more on the compiler.
 Now, over to phobos. Are you planning a group that maintains a version
 of phobos (or the D runtime/standard library)?

Yes exactly, we can use CVS, i know their are others but I've always developed alone never needed to use a versioning system, so whatever the group decides on we can use, i have a server we can use.
 I would suggest that Walter nominates members to this group (I'm fairly
 against selfnomination), perhaps based on applications/election programs

I'm not against that , but Im afraid if we wait for that nothing will ever get done. He is no doubt very busy, and I would defintley like him to read this and us get the go-ahead but it might be weeks before he gets a chance ( once we decide on something we can try to email him ). I agree with most of your vision, just a couple of additions: We'll need a name for the effort, im using dstdlib but we can change that. -- Head of dstdlib: Walter ( approves any changes, applies patches, bundles with DMD ) -- Members: Lars, Charles [ whoelse ? ] ( accepts input from community, decides what changes should be made, implement the changes ). I am only recently using D regularly so I can do the alot of the grunt work ( leave the bigger stuff for more qualified ). Walter we could really use your input if you read this . Thanks, C P.S. Sorry its taking so long to get the imports changed, someone mentioned REBOL on the mailing list a while back and Im taking now as an oppurtunity to learn it. "Lars Ivar Igesund" <larsivi stud.ntnu.no> wrote in message news:bnlevl$29js$1 digitaldaemon.com...
 "Charles Sanders" <sanders-consulting comcast.net> wrote in message
 news:bnk4s1$hof$1 digitaldaemon.com...
 We need to stop talking about getting a phobos library group and just do

 In that spirit I've nominated myself and Lars ( and whoever else is
 interested ).  Ill change the imports to private and upload to
 www.atari-soldiers.com/phobos.html .

 Lars would you be ok with this ?

 C

I am flattered that you have so much confidence in what I'm able/willing

 use my spare time for :) At the moment, the things I do, I do mostly
 because they deep down fullfill some personal need. If they also benefit
 others; great!

 Now, over to phobos. Are you planning a group that maintains a version
 of phobos (or the D runtime/standard library)? More or less a fork of the
 version shipped with DMD? If more people agree with this way of doing
 things, then I guess that patches could be sent to Walter for inclusion in
 the official phobos library. He would then only have the easy job of

 yes or no to applying it. If for some reason, this don't happen we would
 have a situation where "our" phobos would quickly be differentiated from
 the official version, and they might become incompatible, a much worse
 situation than today's.

 I would suggest that Walter nominates members to this group (I'm fairly
 against selfnomination), perhaps based on applications/election programs

 Walter should himself  be a member of the group. Then he should give a
 mandate to the group. Maybe to be some sort of D library standards
 body. The library should then be set up as it's own project in a version
 management system somewhere. And yes, the decision process should be
 completely open, that is all discussions in this body should be available

 those outside of it to read.

 If this wasn't anywhere close to what you were thinking, then I have at
 least
 given my opinion on how the development of the D std lib should be
 executed :) As to the imports; I vote for having them private as suggested
 by Y.T.

 Lars Ivar Igesund

Oct 28 2003
parent reply Ant <Ant_member pathlink.com> writes:
In article <bnmgdl$ln7$1 digitaldaemon.com>, Charles Sanders says...

summary: go ahead, I'll take some time from my D projects if I see I can help. --------------------- (I've been told before not to try humor... specially in english... but...) on previous d-lib shows: Charles said: enought talk, let's see some action Lars said: na, na, we need more talk. Walter said even before that: yes, do it. and now for the continuation:
Yes I agree this would get ugly quick.  A Phobos library group has been
talked about alot but no-one has the time or the "want" to participate, but
I agree with Ilya said if we get a standard group we can let Walter focus
more on the compiler.

I believe open source/volunteer project usualy start with ONE person. Then, if the thing has merit others will join. let's see what could be an example... hummm... D! did Walter assembled a group and ask: If I build it will you use it? No, he just go ahead. Usualy the person that start's the project will head it for a long time and I imagine that's because only projects with merit will attract more people and only a smart guy will create a project with merit. Dreams, i.e. project that didn't produce anything yet, don't attract anybody...
 Now, over to phobos. Are you planning a group that maintains a version
 of phobos (or the D runtime/standard library)?


.. therefore it's going to be difficult to get that group before the thing takes off.
Yes exactly, we can use CVS, i know their are others but I've always
developed alone never needed to use a versioning system, so whatever the
group decides on we can use, i have a server we can use.

group decides

will never happen, decisions by a non existing group...
 I would suggest that Walter nominates members to this group (I'm fairly
 against selfnomination)


I believe that's how open source projects start, I'm president, CEO, sales person, analist, programer and janitor of DUI. (Did DUI actract anybody? (cough, cough) nope ;)
 , perhaps based on applications/election programs

you need elections to delegate, on this age you can just go ahead and code your own libs if you want, If they are good others will use it and help.
I'm not against that , but Im afraid if we wait for that nothing will ever
get done.

I believe your right.
Walter we could really use your input if you read this .

Walter has spoken before on this. He said to go ahead (I'll try to find the actual posts he made later) Don't forget to release early and often, make frequente announcements here to let people know the effort is under way, that way they can take a look and might like it. Sure I'll be willing to help. Ant
Oct 28 2003
next sibling parent "Charles Sanders" <sanders-consulting comcast.net> writes:
Good then its started.

We could still use Walter's input as far as how he wants the changes
handled.

Things that need changing now:

private imports
change the File : Stream CreateFileA ( see Lars' post )
change FileException to FileError ( use deprecated so as not to break old
code )

I can make these changes, then Ill upload.  Jan or Walter could we get a
newsgroup for this ?



"Ant" <Ant_member pathlink.com> wrote in message
news:bnmliv$t2c$1 digitaldaemon.com...
 In article <bnmgdl$ln7$1 digitaldaemon.com>, Charles Sanders says...

summary: go ahead, I'll take some time from my D projects if I see I can help. --------------------- (I've been told before not to try humor... specially in english... but...) on previous d-lib shows: Charles said: enought talk, let's see some action Lars said: na, na, we need more talk. Walter said even before that: yes, do it. and now for the continuation:
Yes I agree this would get ugly quick.  A Phobos library group has been
talked about alot but no-one has the time or the "want" to participate,


I agree with Ilya said if we get a standard group we can let Walter focus
more on the compiler.

I believe open source/volunteer project usualy start with ONE person. Then, if the thing has merit others will join. let's see what could be an example... hummm... D! did Walter assembled a group and ask: If I build it will you use it? No, he just go ahead. Usualy the person that start's the project will head it for a long time and I imagine that's because only projects with merit will attract more people and only a smart guy will create a project with merit. Dreams, i.e. project that didn't produce anything yet, don't attract anybody...
 Now, over to phobos. Are you planning a group that maintains a version
 of phobos (or the D runtime/standard library)?


.. therefore it's going to be difficult to get that group before the thing takes off.
Yes exactly, we can use CVS, i know their are others but I've always
developed alone never needed to use a versioning system, so whatever the
group decides on we can use, i have a server we can use.

group decides

will never happen, decisions by a non existing group...
 I would suggest that Walter nominates members to this group (I'm fairly
 against selfnomination)


I believe that's how open source projects start, I'm president, CEO, sales person, analist, programer and janitor of DUI. (Did DUI actract anybody? (cough, cough) nope ;)
 , perhaps based on applications/election programs

you need elections to delegate, on this age you can just go ahead and code your own libs if you want, If they are good others will use it and help.
I'm not against that , but Im afraid if we wait for that nothing will


get done.

I believe your right.
Walter we could really use your input if you read this .

Walter has spoken before on this. He said to go ahead (I'll try to find the actual posts he made later) Don't forget to release early and often, make frequente announcements here to let people know the effort is under way, that way they can take a look and might like it. Sure I'll be willing to help. Ant

Oct 28 2003
prev sibling next sibling parent "Charles Sanders" <sanders-consulting comcast.net> writes:
Im actually at work ATM so if you have time in the next 3 hours you want to
do it ?

My email is atari-soldiers comcast.net if  you decide to make the changes.

Thanks,
C


"Ant" <Ant_member pathlink.com> wrote in message
news:bnmliv$t2c$1 digitaldaemon.com...
 In article <bnmgdl$ln7$1 digitaldaemon.com>, Charles Sanders says...

summary: go ahead, I'll take some time from my D projects if I see I can help. --------------------- (I've been told before not to try humor... specially in english... but...) on previous d-lib shows: Charles said: enought talk, let's see some action Lars said: na, na, we need more talk. Walter said even before that: yes, do it. and now for the continuation:
Yes I agree this would get ugly quick.  A Phobos library group has been
talked about alot but no-one has the time or the "want" to participate,


I agree with Ilya said if we get a standard group we can let Walter focus
more on the compiler.

I believe open source/volunteer project usualy start with ONE person. Then, if the thing has merit others will join. let's see what could be an example... hummm... D! did Walter assembled a group and ask: If I build it will you use it? No, he just go ahead. Usualy the person that start's the project will head it for a long time and I imagine that's because only projects with merit will attract more people and only a smart guy will create a project with merit. Dreams, i.e. project that didn't produce anything yet, don't attract anybody...
 Now, over to phobos. Are you planning a group that maintains a version
 of phobos (or the D runtime/standard library)?


.. therefore it's going to be difficult to get that group before the thing takes off.
Yes exactly, we can use CVS, i know their are others but I've always
developed alone never needed to use a versioning system, so whatever the
group decides on we can use, i have a server we can use.

group decides

will never happen, decisions by a non existing group...
 I would suggest that Walter nominates members to this group (I'm fairly
 against selfnomination)


I believe that's how open source projects start, I'm president, CEO, sales person, analist, programer and janitor of DUI. (Did DUI actract anybody? (cough, cough) nope ;)
 , perhaps based on applications/election programs

you need elections to delegate, on this age you can just go ahead and code your own libs if you want, If they are good others will use it and help.
I'm not against that , but Im afraid if we wait for that nothing will


get done.

I believe your right.
Walter we could really use your input if you read this .

Walter has spoken before on this. He said to go ahead (I'll try to find the actual posts he made later) Don't forget to release early and often, make frequente announcements here to let people know the effort is under way, that way they can take a look and might like it. Sure I'll be willing to help. Ant

Oct 28 2003
prev sibling next sibling parent reply "Lars Ivar Igesund" <larsivi stud.ntnu.no> writes:
"Ant" <Ant_member pathlink.com> wrote in message
news:bnmliv$t2c$1 digitaldaemon.com...
 Lars said: na, na, we need more talk.

I didn't say that ;) Anyway, I use both first names. I get confused unless addressed as Lars Ivar. As to the other points. I don't really have anything against such a project and I'd love to be part of it (although I probably don't have time ;). I just still think that we really, really need a group that decides a standard API. Thousands of libraries could implement it, but the API should be standard! And this group should probably have elected members (and Walter). Hmm, sounds interesting. Well, count me in to stop by from time to time. And I like Benji's suggestion: core Lars Ivar Igesund
Oct 28 2003
parent Ant <Ant_member pathlink.com> writes:
In article <bnmouo$11us$1 digitaldaemon.com>, Lars Ivar Igesund says...
"Ant" <Ant_member pathlink.com> wrote in message
news:bnmliv$t2c$1 digitaldaemon.com...
 Lars said: na, na, we need more talk.

I didn't say that ;) Anyway, I use both first names. I get confused unless addressed as Lars Ivar.

(You are right. I very sorry, I see you took it lightly, but I got carry way by my joke idea and forgot how things need to be done on the internet.)
 standard API. Thousands of libraries could implement it,
but the API should be standard!

I tried to say that before but you made it clear, unfortunatly nobody can do it (for what ever reason). I also think that API should be common to the target platforms of D, then we could have extensions for specific platforms. Users (developers) can then decide to make a portable aplication or take advantage of facifilites not available on all platforms.
And this group should probably
have elected members (and Walter).

Walter is very important here, but lets imagine that people realy wants to use DUI and DUI only works with the modified version, then they will use the new version (specialy if it doesn't break other stuff) This is not a revolution, I think if we produce interesting thing Walter will pay attention (not before).
Lars Ivar Igesund

Ant
Oct 28 2003
prev sibling parent Ant <Ant_member pathlink.com> writes:
In article <bnmliv$t2c$1 digitaldaemon.com>, Ant says...
In article <bnmgdl$ln7$1 digitaldaemon.com>, Charles Sanders says...


Yes I agree this would get ugly quick.  A Phobos library group has been
talked about alot but no-one has the time or the "want" to participate, but
I agree with Ilya said if we get a standard group we can let Walter focus
more on the compiler.


Walter has spoken before on this.
He said to go ahead (I'll try to find the actual posts he made later)

Here they are (unfortunatly I was not smart enough to make a note of the URLs...) Ant (no wonder one should take the bull by the horns, did you look at the other end?...) ############################################################################ Title: Re: Standard D Library Author: "Walter" <walter digitalmars.com> Date: Sat, 16 Aug 2003 01:29:05 -0700 I want to encourage everyone to help out with the library. My primary focus, as you all have guessed by now, is making the compiler itself the best it can be. Phobos has been a bit neglected as a result. I, of course, will take on the task of the necessary runtime support for the language semantics, such as making sure the exception handling stack unwinder works. But the stuff that makes a library full and great, I'm not too good at. A couple philosophical points on what I think makes a good library: 1) Loose coupling. This is important so that small apps can be created. In Java, it turned out that every class was dependent on every other class, so the smallest app pulled in the entire library. Library modules should be as decoupled as practical. Calling a directory function shouldn't pull in 100k of bloat. 2) The C standard library is not a good module to be emulated. While the C standard library should be available via c.stdio, that's it. C file I/O is particularly slow due to the double buffering it requires. 3) Core library stuff should be easilly implementable on both win32 and linux. With those two covered, it shouldn't be too much trouble to take it anywhere. 4) Modules should be a thin veneer over operating system API's. This will alleviate the temptation of bypassing them and calling the OS directly. 5) Performance matters. 6) Size matters. 7) Make use of the in, out, invariant and unittest features, especially the unittest. 8) As always, be real careful about copyrights. A standard library that's encumbered by disinterested third party copyrights will be a boat anchor holding us all back. D needs to be IP clean, it's the right thing to do. When in any doubt, write it from scratch. 9) Put your name in the code you write! You'll be famous as one of the D pioneers! I think we can learn a lot from how the Python libraries are organized. Their creators seem to know what they're doing <g>. ###################################################################### Title: Re: Library for D Author: "Walter" <walter digitalmars.com> Date: Sun, 28 Sep 2003 17:52:55 -0700 "Sjoerd van Leent" <Sjoerd_member pathlink.com> wrote in message news:bl7c80$q0$1 digitaldaemon.com...
 Dear D Developers,

 I too think that D is a beautiful language. But the language is also very

 This comes with advantages such as new techniques (GC, DBC, Threading) but

 with a lot of disadvantages.

 Well those disadvantages must be eliminated, that's why I had a thought

 creating a Library such as "STL" for C++ or the "java package" for JAVA

 D language.

 I do not know about how the other D fans think about this, but I think

 D language is stable enough to start implementing such a thing. Please let

 know how you think about this.

 Kind regards,
 Sjoerd van Leent

Yes, start implementing it! It also will be a great way to flush out any shortcomings in D.
Oct 28 2003
prev sibling parent J C Calvarese <jcc7 cox.net> writes:
Matthew Wilson wrote:
 Guys
 
 I confess I have so far digested virtually nothing of the import rules, but
 have picked up from the ng that there are problems.
 
 Is anyone in a position to give a 2-3 paragraph of the current mechanism, to
 which the rest can then post the problems, as they see them? I'm sure I'm
 not the only one who would benefit from this.
 
 YT's suggestion sounds sensible, but I just don't have enough experience
 with the importing issues to comment authoritatively.
 
 

YT's suggestion is exactly right. Unless it's a mass-import module (such as dig's main.d or dui's All.d), each module should "private import" the files that it needs. What happens when private imports aren't used is that as windows.d is called by another part of phobos (maybe com.d), the main file is "infected" by everything in windows.d. If you're trying to make use of YT's Win32, his definition of SYSTEMTIME conflicts with windows.d and it has to be either removed, commented out, or versioned to inactivity to compile the project. (By the way, does anyone know why the last two lines of phobos's stream.d imports string and file? As far as I can tell this only invites problems.) I can't resist the urge to use an example to help explain private import: /* orthodox.d */ module orthodox; const int MY_FAVORITE_CONST = 1; /* unorthodox.d */ module unorthodox; const int MY_FAVORITE_CONST = 2; /* mod_a.d */ module mod_a; private import orthodox; /* if this wasn't private, calling.d (below) wouldn't compile: unorthodox.d(5): variable MY_FAVORITE_CONST conflicts with orthodox.MY_FAVORITE_CONST at orthodox.d(5) */ /* calling.d */ import unorthodox; import mod_a; void main() { printf("%d", MY_FAVORITE_CONST); } Justin
 
 
 "Y.Tomino" <demoonlit inter7.jp> wrote in message
 news:bnjtv0$7g2$1 digitaldaemon.com...
 
Hello.

I think we should use "private import" instead of "(public) import" for
platform modules.
"private import" can avoid conflicting identifiers, and high-level or
cross-platform libraries should not show low-level platform modules it

used.
DMD staff, please use "private import" in phobos.
thread.d, file.d, stream.d, etc. look unrelated to Windows, but these
"public import" phobos's windows.d (or linux.d).
That makes it difficult beyond necessity for us to use another windows
module.

Thanks.
YT


Oct 27 2003
prev sibling parent Ant <Ant_member pathlink.com> writes:
In article <bnjtv0$7g2$1 digitaldaemon.com>, Y.Tomino says...
Hello.

I think we should use "private import" instead of "(public) import" for
platform modules.
"private import" can avoid conflicting identifiers, and high-level or
cross-platform libraries should not show low-level platform modules it used.

A version for windows will need to be created but meanwhile this can be used for linux: see attachment All my D progs still compile Ant
Oct 29 2003