Dynamic D Library

[BCS]

Reply to 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?
> 

Unless I has some some compelling reasons not to, yes, I would prefer to. 
Aside from reasons like needing to be able to modularly update the app or 
huge (like GBs) amounts of executable code or some kind of plug-ins via DLLs 
approach, (all of those are exceptions, not the rule) I don't see any compelling 
reason to not statically link all of /my/ code together. It has the distinct 
advantage that things just work without worrying about finding DLLs and checking 
there versions. (OTOH shipping DLLs to be used by other people is a different 
story.)

>> 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 I'm understanding the situation correctly, what you just described is 
ONLY a problem on Windows and only because of a design flaw in the way DLL's 
work. Nobody wants it to work that way and it wouldn't if there were another 
way to do it.
 
>>> 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.

This isn't my expertise but I think you aren't proposing anything new. What 
you are proposing is the way things work /right now/ on Linux and the way 
people wish they would work on Windows.