Re-thinking D's modules

[Marco Leise]

Am Wed, 18 Jul 2012 10:08:19 +0200
schrieb "Dejan Lekic" <dejan.lekic at gmail.com>:

> There are several places for D module system to improve.
> One thing we discussed in the past is the versioning, and as far 
> as I remember, we did not come to any constructive conclusion.
> 
> Java has been criticised often for not having modules. Apparently 
> Java 9 SE will have them, and in my humble opinion, Java 9 module 
> system is going to be far more powerful (or perhaps better word 
> would be USEFUL) than what D currently has.
> 
> More about Java Jigsaw: 
> http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01
> 
> Why is this better? - Speaking from a (senior) software engineer 
> point of view, Java Jigsaw is engineered for large systems where 
> versioning, module-dependency, and module-restrictions are very 
> important.
> 
> I do not like few things about Jigsaw, but most of the things 
> they plan there simply make sense, especially the versioning and 
> module-restrictions, which I urge D developers to take a look and 
> come up with something similar for D2 or D3... This is extremely 
> useful, and will be even more useful once we have shared 
> libraries where we can have N different shared libraries that 
> contain the same module, but different version of it...
> 
> Kind regards
> 

Shared library versioning and dependency management is traditionally done at the OS level (WinSxS, soname, package managers). That may also apply to what is exported aka visible from a library aka module (e.g. export-all policy). Unlike byte code languages like Java or C#, native compiled languages must also consider the target platform in addition to the module version. In addition to this, the scope of a Java module can be anything, up to a complete tomcat web server, whereas the scope of a D module is a single file. A Java module can contain several packages, a D module cannot.

The main difference is in the eco system, in my opinion. Java or .NET are platforms on their own while systems languages integrate with the hardware and OS (starting with calling conventions, up to high-level dependency management). Java is free to innovate here, it is 'their' platform.

Maybe you can elaborate a bit more on what module-restrictions are useful for. I think they are the only feature that I haven't seen in package managers or programming languages. Also the compiler doesn't currently scan shared libraries or even require them to exist. The resolution of symbols is deferred to the linking stage where there are existing mechanisms to hide symbols from a library. And some people like the export-all policy with no hidden symbols, so we are in for a hot discussion on details. :D

P.S.: I am all for a D package manager for developers, that can pull source code and bindings from the web.

-- 
Marco