In article <c7c697$6t7$1@digitaldaemon.com>, Ben Hinkle says...
>Here's a meta-question: what should go in std, what should go in etc and what should go outside the dmd.zip distribution like on dsource?

I think we need to define more clearly what Phobos is.  As I see it, D needs three different kinds of standard library, each of which is related to a different programming-mode that can be done in D:

1) Phobos - This seems to me to like a souped-up LIBC, and will be mostly used when writing D code that mimics plain C.  Basically a non-OO utility library.

2) DTL - Evolution of STL, and obviously something most familiar to C++ users. Provides very flexible OO structures without blackboxing.

3) Yet To Be Made D Class Library - Hopefully something that evolves from the Java and C# class libraries.  An attempt to provide an API for most common tasks, and provide places in the class hierarchy for 3rd party classes to attach to.

I, for one, think it would actually be better, for the sake of clarity, for DTL to remain separate from Phobos.  Let Phobos remain as ONE OF the three standard D libraries.  Let DTL be a separate one.  Thus people who just want to write C-style D won't have to waste space linking in DTL, and in the future those wishing to write like C++ won't have to waste space linking to a C#-style class library.

Owen

In article <c7c697$6t7$1@digitaldaemon.com>, Ben Hinkle says...
>Here's a meta-question: what should go in std, what should go in etc and what should go outside the dmd.zip distribution like on dsource?

I think we need to define more clearly what Phobos is.  As I see it, D needs three different kinds of standard library, each of which is related to a different programming-mode that can be done in D:

1) Phobos - This seems to me to like a souped-up LIBC, and will be mostly used when writing D code that mimics plain C.  Basically a non-OO utility library.

2) DTL - Evolution of STL, and obviously something most familiar to C++ users. Provides very flexible OO structures without blackboxing.

3) Yet To Be Made D Class Library - Hopefully something that evolves from the Java and C# class libraries.  An attempt to provide an API for most common tasks, and provide places in the class hierarchy for 3rd party classes to attach to.

I, for one, think it would actually be better, for the sake of clarity, for DTL to remain separate from Phobos.  Let Phobos remain as ONE OF the three standard D libraries.  Let DTL be a separate one.  Thus people who just want to write C-style D won't have to waste space linking in DTL, and in the future those wishing to write like C++ won't have to waste space linking to a C#-style class library.

Owen

In article <pan.2004.05.06.02.36.41.741820@yahoo.ca>, Ant says...
>
>On Thu, 06 May 2004 09:00:20 +1000, Matthew wrote:
>
>> [Sorry for the post onto the D forum, but I'm going to do that for a little while longer, until the DTL forum achieves its own momentum.]
>> 
>> Not that I'm promising that all suggestions will get in the first version, but I'd like to know what containers people would like to see as part of the standard library.
>> 
>> For any suggestions that do not have direct analogues in the C++ standard library, descriptions of/links to implementations would be helpful.
>> 
>> I'm not planning to put in huge amounts of esoteric containers, but there are certainly things that are missing from the C++ standard library that are missed.
>> 
>> Cheers
>
>Do to your other contributions I'm going to assume that
>DTL will be released on the Synesis License.
>That's absolutelly fine with me.
>I have no problem at all with that, no problem at all
>as long as I'm not forced to download the source code to
>use the final product.
>
>I just want to clarify:
>are these contributions in the form of wishes
>(i.e ideas and priorities - at least)
>to be considered donnations to Synesis?
>

Matthew,
It's prefectly ok if that's the case!
Contributions are also to a better DTL.

just let's make things clear.
maybe even my assumptions are wrong.

I'm not interesting in looking at code with that
clause (see other post) on the Synesis license
or donnating my work anonymously to Synesis
but others might be.

I said before that I would prefer this to be an open
project but having it on the Synesis license is the
second best thing
(but I'm still concerned with access to the source code,
I don't want to be forced to download it to use the libs).

Ant

On Thu, 06 May 2004 10:58:14 +0000, mike parker <mike@aldacron.com> wrote:

>mike parker wrote:
>> 
>> I'd love to see a HashTable. In C++, it is not part of the standard and is implemented as a vendor-specific extension.
>
>Hmm. Then again, is there a use for a HashTable above and beyond what can be done with associative arrays?

I'm not 100% sure about assoc arrays but I still sometimes use
class HashTable(K,V) { V[K] map;
	put(K key, V value ) { map[key]=value; }
	V get( K key) { return map[key]; }
}
and
class Vector(V) { V[] data; opCatAssign(V v) { data ~= v; }

to give Java like behaviour when passed to a function/method i.e. changes made by the callee effect the object held by the caller.

Mike

Matthew wrote:

> [Sorry for the post onto the D forum, but I'm going to do that for a little while
> longer, until the DTL forum achieves its own momentum.]
> 
> Not that I'm promising that all suggestions will get in the first version, but
> I'd like to know what containers people would like to see as part of the standard
> library.
> 
> For any suggestions that do not have direct analogues in the C++ standard
> library, descriptions of/links to implementations would be helpful.
> 
> I'm not planning to put in huge amounts of esoteric containers, but there are
> certainly things that are missing from the C++ standard library that are missed.

Will you be receptive to adding in weird containers if people write and submit them to you?

Chris

> to give Java like behaviour when passed to a function/method i.e. changes made by the callee effect the object held by the caller.

declaring parameters as "inout" will do the same thing - but you have to pass an l-value.

In article <c7ecp6$lin$1@digitaldaemon.com>, Chris Lawson says...
>
>Matthew wrote:
>
[...]
>> 
>> Not that I'm promising that all suggestions will get in the first version, but I'd like to know what containers people would like to see as part of the standard library.
>> 
>> For any suggestions that do not have direct analogues in the C++ standard library, descriptions of/links to implementations would be helpful.
>> 
>> I'm not planning to put in huge amounts of esoteric containers, but there are certainly things that are missing from the C++ standard library that are missed.
>
>Will you be receptive to adding in weird containers if people write and submit them to you?
>
>Chris

I'm curious to see how he replies to your offer.

Matthew is having a bad (as I see it) actitude on relation to this DTL
project.

As I see it he want's to be
<drums><echo>The Man That Created DTL</echo></drums>
(a better title would be "the man that ripped STL")
but he also want's help doing.

If that is true is (if not illegal) at least unetical to ask
for contributions.

of course this is my impression and Matthew is doing a bad job to clarify this - I might be wrong of course.

I propose that we start an independent open project:
ANT
the Alternative New Templateslibrary

It would be LGPLed.

Your contribution could be the first.

Ant

[To D NG: Thread started in D.dtl]

Ant wrote:

> of course this is my impression and Matthew is doing a bad
> job to clarify this - I might be wrong of course.

I agree that Matthew need to clarify his (and Synesis') position here.
And probably Walter too.

I might add to your ANT plans that anyone can make their own implementation of an API. If the API of phobos is considered standard,
but with an unacceptable license, then a reimplementation (clean room)
can be made and released under e.g. LGPL. The only problem is that you
might not be legally entitled to call it Phobos. D Standard Library
shouldn't be a problem though. When I some while ago thought about a
standards group for Phobos, then such free implementations of the API
was one of the (possibly not forwarded) ideas I had for it.

Lars Ivar Igesund

While I believe Matthew is more than capable of looking after himself, I don't understand the need for such severe invectives against him, Ant.   You've brought this up several times without eliciting a response from him.  Now it just looks like you're taunting him for a reply.

Yeah, he wants to be the man that creates DTL.  I would too.  It doesn't mean it's going to be THE DTL.  He's taking a gamble on that.  So far as he knows it might get wripped apart the moment he releases it.

Part of the problem with this "closed" source feel is that he and Walter appear to be in cahoots.  If that's so, you'd better blame Walter too for patronizing him in the matter.

If we really want to guarantee a open DTL project, I suggest that someone start one on dsource.org.  Then if Matthew's DTL turns out useful, we can borrow ideas from it ;-).  Otherwise, those that don't want to show initiative can wait for what Matthew has to offer.

In article <c7g725$glg$1@digitaldaemon.com>, John Reimer says...
>
>I don't understand the need for such severe invectives against him, Ant.

thanks for the advice.

Ant