queue container?

[J Arrizza]

On Mon, Oct 31, 2011 at 7:07 AM, Steven Schveighoffer
<schveiguy at yahoo.com>wrote:
> I personally guarantee that dcollections will persist as long as
std.container's design is not modified to become like dcollections'.
 Simply because I need it for my projects :)  And I'm not going to some
other language any time soon.
> How much weight that pulls with you?  Not sure.

I guess I am unclear on the relationship between D and Digital Mars and you
and Digital Mars. Who drives the policies and direction that D takes? If it
is Digital Mars, then I'd like to see a statement from them indicating that
dcollections will be merged (at some time) into Phobos or that there will
be an official repository for utilities, packages, modules, etc. like
yours. You've already committed to moving it in there.

> I certainly respect that position, and it's a good one to have.  But that
does leave you with a queue-less container situation :)

Yes it does. But I haven't committed to D yet either. I'm looking at it for
the long term. I have a need for a fast, OO language that has a cleaner
"user interface" than C++.

I need it fast since it will most likely be in an embedded product, most
likely on an ARM based processor.

It has to be OO because so far nothing I've seen beats it at keeping source
complexity under control.

By "user interface" I mean not just the syntax of the language but
the surrounding packages, utilities, the compiler, etc.  Java and C# are
popular because of this aspect, and C++ will die because it has less of it.
The reason I'm looking at D at all is because it is taking the approach of
cleaning up some of C++'s issues, it has some great C++ aspects (e.g.
templates), it has some of Java's good things too (the gc), etc. In other
words the overall direction the language is going is solid, and very
promising.

However it is still suffering from a lack of a  large dev kit ala JDK or
CLR. Phobos is just the beginning.

Why all this? Because the biggest impact to 99% of projects is hardly ever
truly difficult technical problems. It is the developer's learning
curve. If we're going to invest in a language, utilities and packages,
please make it 1) easy to learn in the first place and 2) stable so we
don't have to learn it over and over again.

Well, that was a bit of rant. My apologies...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20111101/ab376893/attachment.html>