Thread overview | |||||||
---|---|---|---|---|---|---|---|
|
June 27, 2012 package management | ||||
---|---|---|---|---|
| ||||
I find myself wanting this over and over again. Reading the docs for
Orange made me realize, that I'm not alone.
What's wrong with having imports like:
import mylibrary.mypackage;
replaced with:
import mylibrary.mypackage._;
or
import mylibrary.mypacakge.package;
or
import mylibrary.mypackage.all;
or anything in that fashion?
I thing this is a good idea, because it standardizes access to entire
packages in cases, where such an access makes sense.
Also, there are cases, when some packages and modules aren't meant to
be imported. Implementation packages.
I suppose the best way to handle this is to generate .di files for the
modules, which do need to be imported and distribute those, but it
adds complications and limitations.
Would it make sense to allow marking modules as private or something
to make it only importable from it's own package?
private module myimpl;
/// implementations
Importing a private module from outside of it's immediate package would cause a compilation error.
--
Bye,
Gor Gyolchanyan.
|
June 27, 2012 Re: package management | ||||
---|---|---|---|---|
| ||||
Posted in reply to Gor Gyolchanyan | On Wednesday, 27 June 2012 at 10:34:53 UTC, Gor Gyolchanyan wrote: > I find myself wanting this over and over again. Reading the docs for > Orange made me realize, that I'm not alone. http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16 |
June 27, 2012 Re: package management | ||||
---|---|---|---|---|
| ||||
Posted in reply to Tobias Pankrath Attachments:
| On Wed, Jun 27, 2012 at 2:46 PM, Tobias Pankrath <tobias@pankrath.net>wrote: > On Wednesday, 27 June 2012 at 10:34:53 UTC, Gor Gyolchanyan wrote: > >> I find myself wanting this over and over again. Reading the docs for Orange made me realize, that I'm not alone. >> > > http://prowiki.org/wiki4d/**wiki.cgi?LanguageDevel/DIPs/**DIP16<http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16> > Wonderful. Is there a vote for it? And what about the private module idea? -- Bye, Gor Gyolchanyan. |
June 27, 2012 Re: package management | ||||
---|---|---|---|---|
| ||||
Posted in reply to Gor Gyolchanyan | On 06/27/2012 12:49 PM, Gor Gyolchanyan wrote:
> On Wed, Jun 27, 2012 at 2:46 PM, Tobias Pankrath <tobias@pankrath.net
> <mailto:tobias@pankrath.net>> wrote:
>
> On Wednesday, 27 June 2012 at 10:34:53 UTC, Gor Gyolchanyan wrote:
>
> I find myself wanting this over and over again. Reading the docs for
> Orange made me realize, that I'm not alone.
>
>
> http://prowiki.org/wiki4d/__wiki.cgi?LanguageDevel/DIPs/__DIP16
> <http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16>
>
>
> Wonderful. Is there a vote for it? And what about the private module idea?
>
> --
> Bye,
> Gor Gyolchanyan.
private module does not make sense, because private means 'only
accessible to this module'. What you want is a package module.
|
June 27, 2012 Re: package management | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr Attachments:
| On Wed, Jun 27, 2012 at 3:27 PM, Timon Gehr <timon.gehr@gmx.ch> wrote: > On 06/27/2012 12:49 PM, Gor Gyolchanyan wrote: > >> On Wed, Jun 27, 2012 at 2:46 PM, Tobias Pankrath <tobias@pankrath.net <mailto:tobias@pankrath.net>> wrote: >> >> On Wednesday, 27 June 2012 at 10:34:53 UTC, Gor Gyolchanyan wrote: >> >> I find myself wanting this over and over again. Reading the docs >> for >> Orange made me realize, that I'm not alone. >> >> >> http://prowiki.org/wiki4d/__**wiki.cgi?LanguageDevel/DIPs/__**DIP16<http://prowiki.org/wiki4d/__wiki.cgi?LanguageDevel/DIPs/__DIP16> >> >> <http://prowiki.org/wiki4d/**wiki.cgi?LanguageDevel/DIPs/**DIP16<http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16> >> > >> >> >> Wonderful. Is there a vote for it? And what about the private module idea? >> >> -- >> Bye, >> Gor Gyolchanyan. >> > > private module does not make sense, because private means 'only accessible to this module'. What you want is a package module. > Yes, I thought of naming it a package module, but it semantically conflicts with the module, which represents the entire package (as described in the first issue). -- Bye, Gor Gyolchanyan. |
Copyright © 1999-2021 by the D Language Foundation