Jarrett Billingsley Wrote:

> On Thu, Jul 16, 2009 at 2:12 AM, teo<[email protected]> 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.

Reply via email to