So, what's left on everyone's lists for D1.0 must-have features?

I glanced over the "Pending Peeves" list, but none of those things seems particularly serious to me.

What about the iterators?  Mostly that can be a library thing that comes after the 1.0 release, but it would be nice if foreach at least had the smarts built-in to use an iterator once the method names are decided upon.

--bb

== Quote from Bill Baxter (dnewsgroup@billbaxter.com)'s article
> So, what's left on everyone's lists for D1.0 must-have features?

I think that the "Design by Contract" methods need to be updated to match the documents. Still, there are no AssertException, InException, OutException, and InvariantException in Phobos. To me, Design by Contract is a killer feature seldom found in other languages, yet its implementation (sorry to say that) is still quite poor.

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.  Full dynamic class loading would be nice, but D should at the very least do what C++ does and support overridding virtual method across DLL boundaries.

I have a C++ code base that I want to port to D, but it uses an cross-platform plugin system that I can not replicate with D in its current state.  I don't think this kind of functionality will get into 1.0, and that's OK, just as long as it does with the next year or so.

Other than that, I can see no shortcoming in D that would hinder development.  I'm really very anxious to port my code, but I don't want to start until D is ready.  On the positive side of things, I forsee gobs and gobs of C++ template code shrinking down to nothing, and a fifteen minute compile time reduced to less than a minute.

-Craig

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?

-- 
- EricAnderton at yahoo

"Pragma" <ericanderton@yahoo.removeme.com> wrote in message news:eji7vs$2cla$1@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.

-Craig

"Craig Black" <cblack@ara.com> wrote in message news:eji8g0$2dpp$1@digitaldaemon.com...
>
> "Pragma" <ericanderton@yahoo.removeme.com> wrote in message news:eji7vs$2cla$1@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.

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.

-Craig

Craig Black wrote:
> "Craig Black" <cblack@ara.com> wrote in message news:eji8g0$2dpp$1@digitaldaemon.com...
>> "Pragma" <ericanderton@yahoo.removeme.com> wrote in message news:eji7vs$2cla$1@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

Bill Baxter wrote:
> So, what's left on everyone's lists for D1.0 must-have features?

Although D doesn't currently use a generational copying collector, it would be nice if we could anticipate the hurdles to implementing a copying GC in the current language, and develop some syntactic extensions to the language for copying with a copying GC.

In a language like Java, where there are only reference types and primitives (i.e., no pointers), the implementation of a copying GC is pretty straightforward, because when an object gets moved to a new location in memory, you never have to worry that it will leave behind a orphaned pointer.

In C#, which does allow pointers, certain blocks of code are marked as unsafe, and certain objects or pointers can be temporarily "pinned" to their current memory location. If the GC thread comes to life during the execution of an unsafe block, the GC will ignore any objects or pointers that have been pinned at their current location. Those items will be collected later, during a subsequent GC run, after they've been "un-pinned".

It would be nice, before version 1.0 of D, to get the syntax in place for pinning pointers. With the current GC, all objects are permanently "pinned" anyhow, so this implementation would be semantically correct, even if it didn't do anything :) But at least, with the syntax in place, we'd be prepared for the eventual introduction of a generational copying GC, when such a thing is inevitably implemented.

--benji

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@yahoo.removeme.com> wrote in message news:ejic3q$2jdj$1@digitaldaemon.com...
> Craig Black wrote:
>> "Craig Black" <cblack@ara.com> wrote in message news:eji8g0$2dpp$1@digitaldaemon.com...
>>> "Pragma" <ericanderton@yahoo.removeme.com> wrote in message news:eji7vs$2cla$1@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

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.  Full dynamic class loading would be nice, but D should at the very least do what C++ does and support overridding virtual method across DLL boundaries.

I'm not sure why that wouldn't work now. What happens when you try it?