www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Scope of D packages

reply Jakob Jenkov <jakob jenkov.com> writes:
I'm coming from Java where "packages" are not that much more than 
directories. Each class can be exposed or hidden inside a package 
etc.

In Java it is common that an API consists of many packages and 
subpackages. All classes are simply wrapped up in a JAR (Zip) 
file, and then they can be used as a library.

What is common in D?

Does a library have all its classes inside the same package (same 
directory) ? Or can you have multiple packages / subpackages 
inside the same library *and* same source root?
Dec 18 2015
next sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Friday, 18 December 2015 at 23:20:34 UTC, Jakob Jenkov wrote:

 I'm coming from Java where "packages" are not that much more 
 than directories. Each class can be exposed or hidden inside a 
 package etc.

 In Java it is common that an API consists of many packages and 
 subpackages. All classes are simply wrapped up in a JAR (Zip) 
 file, and then they can be used as a library.

 What is common in D?

 Does a library have all its classes inside the same package 
 (same directory) ? Or can you have multiple packages / 
 subpackages inside the same library *and* same source root?


each sub directory in a package is also a package

lib/package.d : allow to put all the lib modules as public import
lib/module1.d : this is module 1 from package lib
lib/module2.d : this is module 2 from package lib
lib/sub1/package.d : allow to put all the lib.sub1 modules as 
public import
lib/sub1/module1: this is module 1 from package lib.sub1
lib/sub1/module2: this is module 2 from package lib.sub1

but when you compile 'lib' library it's a monolithic *.a or *.lib 
file, which still requires the sources.

look at https://github.com/gecko0307/dlib/tree/master/dlib 
structure for example.
Dec 18 2015
parent reply cym13 <cpicard openmailbox.org> writes:
On Saturday, 19 December 2015 at 00:09:16 UTC, Basile B. wrote:

 On Friday, 18 December 2015 at 23:20:34 UTC, Jakob Jenkov wrote:

 I'm coming from Java where "packages" are not that much more 
 than directories. Each class can be exposed or hidden inside a 
 package etc.

 In Java it is common that an API consists of many packages and 
 subpackages. All classes are simply wrapped up in a JAR (Zip) 
 file, and then they can be used as a library.

 What is common in D?

 Does a library have all its classes inside the same package 
 (same directory) ? Or can you have multiple packages / 
 subpackages inside the same library *and* same source root?


 each sub directory in a package is also a package

 lib/package.d : allow to put all the lib modules as public 
 import
 lib/module1.d : this is module 1 from package lib
 lib/module2.d : this is module 2 from package lib
 lib/sub1/package.d : allow to put all the lib.sub1 modules as 
 public import
 lib/sub1/module1: this is module 1 from package lib.sub1
 lib/sub1/module2: this is module 2 from package lib.sub1

 but when you compile 'lib' library it's a monolithic *.a or 
 *.lib file, which still requires the sources.

 look at https://github.com/gecko0307/dlib/tree/master/dlib 
 structure for example.


To be exact it doesn't need the sources, it needs the function 
signatures and type definitions so the equivalent of C header 
files. If you don't want to share the full sources with your 
library you can generate those header files automatically using 
the -H flag in dmd. It will produce a "D interface" file with a 
"di" extension.
Dec 18 2015
next sibling parent reply Jakob Jenkov <jakob jenkov.com> writes:
 To be exact it doesn't need the sources, it needs the function 
 signatures and type definitions so the equivalent of C header 
 files. If you don't want to share the full sources with your 
 library you can generate those header files automatically using 
 the -H flag in dmd. It will produce a "D interface" file with a 
 "di" extension.


But - if the library was open source, it would be better to just 
share the sources than a compiled file? (In Java we share/use the 
zipped JAR file with compiled classes).
Dec 18 2015
next sibling parent cym13 <cpicard openmailbox.org> writes:
On Saturday, 19 December 2015 at 00:52:40 UTC, Jakob Jenkov wrote:

 To be exact it doesn't need the sources, it needs the function 
 signatures and type definitions so the equivalent of C header 
 files. If you don't want to share the full sources with your 
 library you can generate those header files automatically 
 using the -H flag in dmd. It will produce a "D interface" file 
 with a "di" extension.


 But - if the library was open source, it would be better to 
 just share the sources than a compiled file? (In Java we 
 share/use the zipped JAR file with compiled classes).


If it's open source it's better to share the sources, sure. As 
the compiler is able to do more optimization when it has all the 
sources at hand it is customary to limit the use of shared 
libraries and just compile everything at once (although you can 
quickly run into things like memory limitations as it demands 
quite a lot of resources). Typically you'd segment your 
compilation by module if needed.

If you are to give the sources (with or without a standalone lib) 
then you allow your users to benefit from such optimizations if 
they want to, so it's better to give the sources when possible. D 
Interface files are there mostly (only?) to answer the 
problematic of closed source libraries.
Dec 18 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-12-19 01:52, Jakob Jenkov wrote:


 But - if the library was open source, it would be better to just share
 the sources than a compiled file?


Yes. The convention is to use the package manager Dub [1]. It only 
allows source distribution and it handles compiling and all dependencies 
as well.

[1] http://code.dlang.org/

-- 
/Jacob Carlborg
Dec 19 2015
prev sibling next sibling parent reply Enamex <enamex+d outlook.com> writes:
On Saturday, 19 December 2015 at 00:46:12 UTC, cym13 wrote:

 To be exact it doesn't need the sources, it needs the function 
 signatures and type definitions so the equivalent of C header 
 files. If you don't want to share the full sources with your 
 library you can generate those header files automatically using 
 the -H flag in dmd. It will produce a "D interface" file with a 
 "di" extension.


How does this interact with templates and introspective code?
Dec 19 2015
parent Jonathan M Davis via Digitalmars-d-learn writes:
On Saturday, December 19, 2015 17:09:49 Enamex via Digitalmars-d-learn wrote:

 On Saturday, 19 December 2015 at 00:46:12 UTC, cym13 wrote:

 To be exact it doesn't need the sources, it needs the function
 signatures and type definitions so the equivalent of C header
 files. If you don't want to share the full sources with your
 library you can generate those header files automatically using
 the -H flag in dmd. It will produce a "D interface" file with a
 "di" extension.


 How does this interact with templates and introspective code?


Templates must always have their entire source available (even in .di
files), and any function that you want to be inlined or to use with CTFE
must have its entire source available. Also, any functions involving auto in
their signature will have to have their full source available.  However, at
the moment, I can't think of any compile time introspection which isn't
going to work with just the signatures, because that's all that that stuff
looks at anyway.

In general, I would strongly argue that unless you _need_ to hide your
source code, you should not use .di files, and given how heavily a lot of D
code uses templates, a large portion of the D code out there _can't_ hide
its source code. As I understand it, .di files are there primarily for the
corporate folks who insist on hiding their source, since some companies
would refuse to use a language that did not allow them to hide their source
code.

- Jonathan M Davis
Dec 19 2015
prev sibling parent Basile B. <b2.temp gmx.com> writes:
On Saturday, 19 December 2015 at 00:46:12 UTC, cym13 wrote:

 To be exact it doesn't need the sources, it needs the function 
 signatures and type definitions so the equivalent of C header 
 files. If you don't want to share the full sources with your 
 library you can generate those header files automatically using 
 the -H flag in dmd. It will produce a "D interface" file with a 
 "di" extension.


Of course. Thanks for the correction. Actually I've never seen 
anybody that uses the d interface files for this purpose, but in 
theory it would work (e.g commercial non-OSS static library).
Dec 19 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-12-19 00:20, Jakob Jenkov wrote:

 I'm coming from Java where "packages" are not that much more than
 directories. Each class can be exposed or hidden inside a package etc.

 In Java it is common that an API consists of many packages and
 subpackages. All classes are simply wrapped up in a JAR (Zip) file, and
 then they can be used as a library.

 What is common in D?

 Does a library have all its classes inside the same package (same
 directory) ? Or can you have multiple packages / subpackages inside the
 same library *and* same source root?


Organizing the code in D is quite similar as in Java. Although there's 
no enforcement of a one to one mapping of classes and files. In D you 
can have multiple public symbols in a module (file). Classes, structs, 
functions, variables and so on.

Instead of using the reverse domain name as in Java, the convention is 
to name the root package the same as the library/project name.

The distribution is done using Dub (see my other post).

-- 
/Jacob Carlborg
Dec 19 2015