June 03, 2013 Re: [phobos] Update on Importing Packages [Was Re: install targets] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel Murphy | On Monday, June 03, 2013 02:38:33 Daniel Murphy wrote: > IIRC this is the "import blah;" vs "import blah : *" that we discussed at the conference. It's not. It works just fine when importing something like std.datetime.all which publicly imports the package, but with your changes, the public imports in package.d don't allow std.datetime.DosFileTime to work, unlike with std.datetime.all. To quote my comment in the pull request: ----------------- I don't think that this is a problem with the proposal that this is trying to implement. I think that the problem is in the implementation. Note that using a public selective import didn't work either, and both aliasing and selective importing std.datetime.common.DosFileTime in std.datetime.package should have worked, even if simply publicly importing std.datetime.common didn't. Also, if I create three modules like so: a.d int i = 7; b.d public import a; c.d import std.stdio; import b; void main() { writeln(b.i); } the code compiles and prints 7. Module c is able to use b.i as if i were in b when in fact it's in a. So, the public importing itself does what we want for this proposal. I don't think that there's necessarily anything wrong with the proposal that this pull request is trying to implement. It would work if you were trying to import std.datetime.all. and then use std.datetime.all.DosFileTime. I think that the problem has to be in how the implementation translates std.datetime.package into std.datetime. Clearly, specifying the full import path doesn't work with it even though it works with public imports normally. ----------------- > I can't remember what our resolution for that is, so I'll > have another go when I do. And when I'm done with DAC. And I finish > exams. And I finish the DMD -> D port. etc Haven't given up, just no time. Well, life happens. I'm plenty busy as well. I just figured that I'd ask, since you never responded to my comment in the pull request, and I wasn't sure whether you'd read it or not. - Jonathan M Davis _______________________________________________ phobos mailing list phobos@puremagic.com http://lists.puremagic.com/mailman/listinfo/phobos |
June 03, 2013 Re: [phobos] Update on Importing Packages [Was Re: install targets] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis Attachments:
| Ok. It's on the list and hopefully have time to work on it in a couple of weeks.
On Mon, Jun 3, 2013 at 2:45 AM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:
> On Monday, June 03, 2013 02:38:33 Daniel Murphy wrote:
> > IIRC this is the "import blah;" vs "import blah : *" that we discussed at the conference.
>
> It's not. It works just fine when importing something like std.datetime.all
> which publicly imports the package, but with your changes, the public
> imports
> in package.d don't allow std.datetime.DosFileTime to work, unlike with
> std.datetime.all. To quote my comment in the pull request:
>
> -----------------
> I don't think that this is a problem with the proposal that this is trying
> to
> implement. I think that the problem is in the implementation. Note that
> using
> a public selective import didn't work either, and both aliasing and
> selective
> importing std.datetime.common.DosFileTime in std.datetime.package should
> have
> worked, even if simply publicly importing std.datetime.common didn't.
> Also, if
> I create three modules like so:
>
> a.d
>
> int i = 7;
> b.d
>
> public import a;
> c.d
>
> import std.stdio;
> import b;
>
> void main()
> {
> writeln(b.i);
> }
> the code compiles and prints 7. Module c is able to use b.i as if i were
> in b
> when in fact it's in a. So, the public importing itself does what we want
> for
> this proposal.
>
> I don't think that there's necessarily anything wrong with the proposal
> that
> this pull request is trying to implement. It would work if you were trying
> to
> import std.datetime.all. and then use std.datetime.all.DosFileTime. I think
> that the problem has to be in how the implementation translates
> std.datetime.package into std.datetime. Clearly, specifying the full import
> path doesn't work with it even though it works with public imports
> normally.
> -----------------
>
> > I can't remember what our resolution for that is, so I'll
> > have another go when I do. And when I'm done with DAC. And I finish
> > exams. And I finish the DMD -> D port. etc Haven't given up, just no
> time.
>
> Well, life happens. I'm plenty busy as well. I just figured that I'd ask,
> since
> you never responded to my comment in the pull request, and I wasn't sure
> whether you'd read it or not.
>
> - Jonathan M Davis
> _______________________________________________
> phobos mailing list
> phobos@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
|
Copyright © 1999-2021 by the D Language Foundation