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?

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.

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.

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

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.

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

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

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?

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

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