What are you including in the DTL or (I'm guessing) D Template Library? Are you going to create a iostream STL clone because the one in Phobos isn't finished and it is mostly C in a class which is mostly worthless.

> What are you including in the DTL or (I'm guessing) D Template Library?

DTL will be two things:

1. A description of concepts & protocols for collections in D, that may be
applied throughout the D world, along with supporting mixins and interfaces.
These protocols are influenced by STL, Java, Ruby and D itself, and they may all
be supported in a maximally efficient manner.
2. An implementation of specific container template classes, e.g. List, Map,
SList, Queue, Deque, Stack etc. according to the protocol.

There will also be a variety of algorithms, although I expect that that side of the library will mostly grow from demand/submission after it's being used.

> Are you going to create a iostream STL clone because the one in Phobos isn't finished and it is mostly C in a class which is mostly worthless.

No. I don't think the IOStream model is one that anyone should try and ape, and I have no intention of doing so myself.

In terms of the implementation of the collection concepts in container classes, DTL will restrict itself to *containers only*. (I think keeping a single mission will make it more easy to create, use, digest, maintain.) But its concepts, protocols, mixins, and interfaces will lend themselves to any manipulation of collections (in the broadest sense), so it may well be that others may reuse them for work in the areas of streaming, or any other area. (I myself plan to borrow peices from DTL to enhance std.recls once it's ready.)

As for what one should be using for streaming, I can't answer that, but I can tell you I plan to dig deep into Mango in the next week or so, as soon as my schedule frees up.

Matthew

Well, I'm not happy with std.stream class and I'm glad that some one is making a list, queue, deque, etc since the crap I would make would be well, crap and that would suck with projects that I'm working on. Are all of these classes going to be available at release or are you just supplying the container classes and making the rest of us create the rest?

From what I read, I would say yes but I have a feeling that I may be wrong. You are going to include operator overloading along with the function? Java has a way of being extremely typeful at all times and using operators would save space and be easier to program with.

Good luck and I can't wait until you finish.

"Gold Dragon" <dragonwing@dragonu.net> wrote in message news:ccm1ar$284l$1@digitaldaemon.com...
> Well, I'm not happy with std.stream class and I'm glad that some one is
> making a list, queue, deque, etc since the crap I would make would be
> well, crap and that would suck with projects that I'm working on. Are
> all of these classes going to be available at release or are you just
> supplying the container classes and making the rest of us create the rest?
>
>  From what I read, I would say yes but I have a feeling that I may be
> wrong. You are going to include operator overloading along with the
> function? Java has a way of being extremely typeful at all times and
> using operators would save space and be easier to program with.
>
> Good luck and I can't wait until you finish.

What don't you like about std.stream? Walter doesn't work on it so it really seems to be up to us users to add features to it or "fix" it. There have been several recent threads in digitalmars.D about streams and i/o so you might want to check those out, too.

-Ben

"Gold Dragon" <dragonwing@dragonu.net> wrote in message news:ccm1ar$284l$1@digitaldaemon.com...
> Well, I'm not happy with std.stream class and I'm glad that some one is making a list, queue, deque, etc since the crap I would make would be well, crap and that would suck with projects that I'm working on.

Well, don't get your hopes up. Mine might be crap as well.

> Are
> all of these classes going to be available at release or are you just
> supplying the container classes and making the rest of us create the rest?

When I worked on this in March, I wrote List, Map, Queue, Set, Stack and Vector, and that's the current state-of-play.

Nothing much has changed since then, as I was waiting for some advance of technology (mixins) and then bugs and other work has held me up since. But I will be getting down to it again next week, as my deadline for the current work is next monday.

The first release will likely contain just those five containers, as I'd rather focus on getting the quality right initially.

My guess/hope is that people will work with the initial suite of classes, and from the feedback some classes will be altered and new ones will be born, created either by me or anyone else who wants to contribute.

But as I said, my intention is that things that reside in std.dtl.* are either bona-fide containers, or mixins or interfaces or algorithms. Pseudo-containers, like the myriad ones in STLSoft (http://stlsoft.org/) will not be part of DTL per-se. The reason for this is to keep it clean, efficient, small, maintainable and, most importantly, comprehensible by the vast majority of users. That last quality is very much lacking in STL.

But DTL will _absolutely_ support the provision of STL-compliant/compatible pseudo-containers, by prescribing concepts/models and by providing interfaces and mixins. The ethos is to enable compatibility, but not demand it. (I'm a big fan of low coupling and leaving decisions with the developer, just like Walter, so I don't expect this ethos to be unwelcome.)

>  From what I read, I would say yes but I have a feeling that I may be
> wrong. You are going to include operator overloading along with the
> function?

Depends on which operators you mean. I'm not going to have any counter-intuitive operators (e.g. << !!)

> Java has a way of being extremely typeful at all times and using operators would save space and be easier to program with.

Java-like containers are one of four containment models supported. They'll be available to those who need/want them, but have no overhead for those that want to use another model.

> Good luck and I can't wait until you finish.

ha! Well, yes, it would be nice to get the first version out soon. To whit, I must get on with what I'm currently working on, so I am indeed free next week.

But, as I've said all along, it'll be ready in time for D 1.0, and there's no change in that intention/likelihood.

Cheers (and thanks for the interest)


-- 
Matthew Wilson

Author: "Imperfect C++", Addison-Wesley, 2004
    (http://www.imperfectcplusplus.com)
Contributing editor, C/C++ Users Journal
    (http://www.synesis.com.au/articles.html#columns)
Director, Synesis Software
    (www.synesis.com.au)
STLSoft moderator
    (http://www.stlsoft.org)

-----------------------------------------------------

From what I heard a Set is like a tree or it could be a hash. If I want a tree than I want to define its behavior myself. As such I would rather like to have a Set or tree of objects as from a struct or another class. If a Set is not a tree then there probably should be one.

Well, I only have less than a year of C++ so whatever you can make would be better than anything I can do. I was actually planning on hacking STL and porting the code over to D but it is much to difficult to understand the C++ code. You doing all the work saves me a lot of time, which makes for more time editing, recreating, destroying, molding, and do whatever I like to your code as long as there isn't a copyright preventing me to do so.

Where will you post the Package when you are done?

"Gold Dragon" <dragonwing@dragonu.net> wrote in message news:ccv4bb$cgp$1@digitaldaemon.com...
> From what I heard a Set is like a tree or it could be a hash. If I want a tree than I want to define its behavior myself. As such I would rather like to have a Set or tree of objects as from a struct or another class. If a Set is not a tree then there probably should be one.

I think we'll define Set to have its internals implementation-dependent.

I agree that an explicit Tree would be good.

> Well, I only have less than a year of C++ so whatever you can make would be better than anything I can do.

You might be right. Time will tell ...

> I was actually planning on hacking STL
> and porting the code over to D but it is much to difficult to understand
> the C++ code. You doing all the work saves me a lot of time, which makes
> for more time editing, recreating, destroying, molding, and do whatever
> I like to your code as long as there isn't a copyright preventing me to
> do so.

It's all being written under the "D" license. There'll be no particular license restrictions preventing you, or anyone else, from modifying it, but only approved changes will be rolled back into Phobos.

> Where will you post the Package when you are done?

Not sure yet. We'll make sure it's well publicised before posting.

Cheers

Matthew