www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - new DIP15: Import of packages

reply "Martin Nowak" <dawg dawgfoto.de> writes:
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP15
Oct 18 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-10-18 09:38, Martin Nowak wrote:

 http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP15


What's the advantage of this compared to importing the "_.d" file 
explicitly, i.e. "import pkg._;" ?

-- 
/Jacob Carlborg
Oct 18 2011
next sibling parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
1. Standardized and guaranteed to work in a similar manner every time.
2. Less eye-trash in the code.
3. Opportunity to improve semantics of importing a package without
needing to refactor lots of code.

On Tue, Oct 18, 2011 at 3:27 PM, Jacob Carlborg <doob me.com> wrote:

 On 2011-10-18 09:38, Martin Nowak wrote:

 http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP15


 What's the advantage of this compared to importing the "_.d" file
 explicitly, i.e. "import pkg._;" ?

 --
 /Jacob Carlborg
Oct 18 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-10-18 13:40, Gor Gyolchanyan wrote:

 1. Standardized and guaranteed to work in a similar manner every time.
 2. Less eye-trash in the code.
 3. Opportunity to improve semantics of importing a package without
 needing to refactor lots of code.


Ok, makes sense. Although, I would prefer if this "_.d" file wouldn't 
need to be created manually.


 On Tue, Oct 18, 2011 at 3:27 PM, Jacob Carlborg<doob me.com>  wrote:

 On 2011-10-18 09:38, Martin Nowak wrote:

 http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP15


 What's the advantage of this compared to importing the "_.d" file
 explicitly, i.e. "import pkg._;" ?

 --
 /Jacob Carlborg





-- 
/Jacob Carlborg
Oct 18 2011
parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
How do you imagine the process of importing a package without having a
dedicated "default" module for it?

On Tue, Oct 18, 2011 at 4:29 PM, Jacob Carlborg <doob me.com> wrote:

 On 2011-10-18 13:40, Gor Gyolchanyan wrote:

 1. Standardized and guaranteed to work in a similar manner every time.
 2. Less eye-trash in the code.
 3. Opportunity to improve semantics of importing a package without
 needing to refactor lots of code.


 Ok, makes sense. Although, I would prefer if this "_.d" file wouldn't nee=


d

 to be created manually.


 On Tue, Oct 18, 2011 at 3:27 PM, Jacob Carlborg<doob me.com> =A0wrote:

 On 2011-10-18 09:38, Martin Nowak wrote:

 http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP15


 What's the advantage of this compared to importing the "_.d" file
 explicitly, i.e. "import pkg._;" ?

 --
 /Jacob Carlborg





 --
 /Jacob Carlborg
Oct 18 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-10-18 16:50, Gor Gyolchanyan wrote:

 How do you imagine the process of importing a package without having a
 dedicated "default" module for it?


I have no idea. What about how it works in other languages that support 
this, i.e. Java and Scala. At least it would be nice to have.


-- 
/Jacob Carlborg
Oct 18 2011
prev sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
On Tue, 18 Oct 2011 13:27:18 +0200, Jacob Carlborg <doob me.com> wrote:


 On 2011-10-18 09:38, Martin Nowak wrote:

 http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP15


 What's the advantage of this compared to importing the "_.d" file  
 explicitly, i.e. "import pkg._;" ?


It is a paradigm shift to import a package.
Consider import std with a small sensible collection
of defaults from std.stdio, std.range and std.algorithm.
Or import gtkd and giving the library writer a defined place
for startup hooks. Also this scales much better to import
packages from non-directories, e.g. zip files or urls.

The other keypoint is that you have a simple way to obtain a packages  
symbol.
This symbol can be handled as any other symbol,
e.g. apply protection, pass it as template parameter or alias different  
packages based on a version tag.
Most of this is already possible but requires you to import a submodule to  
obtain the package symbol.

martin
Oct 18 2011