Dynamic D Library

[teo]

Jarrett Billingsley Wrote:

> On Thu, Jul 16, 2009 at 2:12 AM, teo<teo.ubuntu at yahoo.com> wrote:
> > One major problem is the D's inability to create dynamic libraries. D is a great language, but without that ability it can only be used for small programs, tools, etc. and never in production.
> 
> For one, I question your logic that without dynamic libraries, D can
> never be more than a hobby language.

Would you develop an application (excluding tools) as a huge monolithic executable?


>  For two, there is *no problem*
> with creating D libraries on any platform other than Windows, and it
> is entirely through Windows' fault that it has the problems it does
> with DLLs.
> 
Well, let us assume that you can create dynamic libraries in D and you need to include in each of them Phobos (later maybe just the D Runtime). What is the benefit of that? Can you imagine all your nice dynamic libraries (DLLs, SOs, etc.) written in D and all of them including a huge “payload”? Wouldn't it be better just a simple library only containing the stuff you need?


> > If the intention is to replace C/C++ some day, why not just provide a dynamic D library? (like in this project: http://www.dsource.org/projects/ddl/) It can contain only compiled D code accompanied with meta-data like platform, version, etc. and be used only by D programs. No runtime is needed within the DDL. When the DDL is loaded it will be managed by the same GC which manages the program itself. Even Phobos can be a DDL.
> >
> > Maybe I am missing something and that's why I would like to hear your opinion.
> 
> You're missing something :)  DDL doesn't require you to have a D
> runtime in the shared library because unlike DLLs, DDLs can have
> unresolved externals.  That's the main issue: DLLs must have performed
> all their symbol resolution at link-time, and cannot automatically
> load symbols out of the host.  So, you end up with all the runtime
> duplicated in the DLL.  DDLs, as well as shared libraries on _every
> other platform_, allow you to have unresolved externals in the shared
> library which are linked at *load-time*, so that there is one runtime,
> which is in the host, which all the shared libraries use.

Perhaps I am missing something else ;) because that is exactly my point. DDLs need neither runtime nor Phobos statically linked. Have a look at Java for instance - Java developers create packages (not DLLs) and that is enough. They deploy just the relevant code - no extra bytes. And yes, I know that the JVM is behind the scene. Exactly this is the idea here: the D Runtime can act like the JVM.