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

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

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

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

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

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

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

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

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

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

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