What's left for 1.0?

[Craig Black]

So it's possible for DDL to work in Linux.  Are there plans for implementing 
this in the near future?  If so how long would you expect it to take?

Also, it seems that Walter will eventually implement some kind of run-time 
reflection.  How do you think native reflection would influence DDL?  It 
seems to me that it would make it easier to do what  you are doing.

-Craig

"Pragma" <ericanderton at yahoo.removeme.com> wrote in message 
news:ejic3q$2jdj$1 at digitaldaemon.com...
> Craig Black wrote:
>> "Craig Black" <cblack at ara.com> wrote in message 
>> news:eji8g0$2dpp$1 at digitaldaemon.com...
>>> "Pragma" <ericanderton at yahoo.removeme.com> wrote in message 
>>> news:eji7vs$2cla$1 at digitaldaemon.com...
>>>> Craig Black wrote:
>>>>> This is not a 1.0 blocker, but it is a blocker my development.  D 
>>>>> doesn't have a good solution for cross-platform dynamic libraries.
>>>> Out of curiosity, what feature set are you looking for when it comes to 
>>>> dynamic libs being "cross-platform"?  Are you looking for write-once, 
>>>> deploy everywhere, some other killer feature, or is just 
>>>> seamless/effortless compilation-per-platform good enough?
>>> Like I said, full class loading would be nice, but my requirement is 
>>> what C++ currently offers.  That is, I can compile the same code on 
>>> Windows and Linux and get a .dll and an .so that are linked at run-time. 
>>> I want to be able to use an abstract class to interface to them.
>
> Believe me, I know.  This is *the* way to do things in an OOP-based 
> language.  Once I saw java doing that 10 years ago, I haven't looked back.
>
> And to keep this marginally on-topic, I'll add that I never expect 
> something like DDL to be embraced by Walter or DMD anyway.  It's the kind 
> of project that is really quite happy living as a lib.
>
>> BTW, I didn't mean to belittle DDL in any way.  Sorry if it seemed like 
>> that is what I was doing.  I might be able to use DDL instead of an 
>> abstract class if DDL worked in Linux.  However, I don't think this is 
>> currently possible since last I heard DMD didn't produce shared objects 
>> in linux. Correct me if I'm wrong.
>
> It's no problem Craig.  I know you've posted around here for a long time, 
> but I couldn't recall (for the moment anyway) if you'd given it a shot yet 
> or not.  Plus I'm always fishing for better ways to do things, and insight 
> from people who think it's not the right tool for the job.
>
> But to be fair DDL isn't 100% on Linux yet.  Provided it was, you could do 
> just what you're talking about: compile once per platform and deploy like 
> you do with .dll and .so files now.  DDL will be able to load ELF and Ar 
> files much like it can do OMF .obj and .lib files now.
>
> As far as I know, DMD can create the needed file types to pull this off. 
> DMD's shared-object capability (absent or not) isn't a problem, as DDL has 
> a healthy appitite for ELF Modules straight from the compiler.  The 
> runtime linker does the rest.
>
> Futhermore, Shared-Objects of both the relocatable and non-relocatable 
> varieties are by definition internally linked, which makes them 
> questionable candidates for DDL's "full-linking" design anyway.  I'm sure 
> others will find creative ways to exploit them through DDL, but they're 
> not a concern at this point.
>
> So that leaves only one sticking point: the differences in exception 
> handling between operating systems (future 64bit compatibility 
> notwithstanding).  I haven't researched it fully, but I'm willing to bet 
> that DDL could insert a thunk at link time that can bridge the gap for 
> suitably coded (read: no OS-specific code) modules.
>
> -- 
> - EricAnderton at yahoo