It's, as we say in Yorkshire, as rough as a badger's arse.

However, it's here, and I guess that's something at least. I can do no more for a few days, as I've spent the last three on this when I should have been earning cold hard green stuff. It's going to be a tough w/e ...

Notable points for anyone of an investigative nature:

1. List, Map, Stack, Queue and Vector all do "real things", and should be manifestly useful for people with real needs
now, so long as they're happy with just foreach enumeration. Set is nothing but a shell at the moment.
2. Off the top of my head, only List does the range composition stuff yet. Check out test/list_test.d, which uses
collect, and has some examples of composed select().
3. The lib depends on std.box, std.boxutil and std.type.traits, none of which are yet part of Phobos. In fact they may
never be, but that's not terribly important at the moment. They can be sorted later.
4. There are many untrackable (or at least untracked) linker problems with simple utility templates, so you'll see lots
of places where the std.dtl.common.swap template is commented out and hard coded. I have no idea why the linker does
this with in some link-units and not others that use the same templates. Something TBD.
5. There are no docs. You'll have to be guided from what I've posted over the last few weeks and months, until at least
DTL 0.1.2. :) Hopefully, if people ask smart questions, it'll help me write better docs. Just remember, there are four
enumeration modes: foreach, ranges (composable foreachable thingies), interfaces (whether Object or parameterised; both
will be supported), and iterators (this code has not been enabled/compiled for months, so I have *no idea* what it'll
do. define UseIterators at your own peril).

I will check in for responses over the next few days, but I won't be able to do any more on this until late next week. Hopefully I can have isolated some nasty compiler-crash test cases and dispatched them off to big W, which will help with some aspects (notably parameterised interface enumeration, i.e. deriving from IContainer!(int), etc.).

Cheers

-- 
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)

"Youth ages, Immaturity is outgrown, Ignorance can be educated, drunkeness sobered. But stupid lasts forever", Aristophenes

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

Oh, I forgot to mention, I haven't worked out a particularly sophisticated strategy as yet, since I want to see what nuggets all you smart folks might dig up. But I have thought about the following:

- I need to provide isolated test cases for the 5-10 compiler/linker bugs I've seen, that I can then get over to big-W.
Hopefully this can be done, and the bugs fixed, over the next week or so.
- I expect that once you guys digest what I've done, you'll make suggestions for improvements, and some of the glaring
omissions, which'll filter in over the next few weeks also.
- Docs will be provided, but more in a "philosophy" form at first, since some aspects are yet to mature (e.g. Iterators)

I am hoping that the actual implementation of new container types will actually be done by other people, including Ben, presumably in concert with me as far as the enumeration models and such are concerned. (Although I've written gazillions of containers over the years, I have *no doubt* that other among you will know how to write better Trees, Multimaps and such than me, since I'm pretty sequence-container fucused, so I welcome all contributions.) There will also be a rather large demand for algorithms, so maybe Sean can be persuaded to poke his magic wand in that side of things.

I am also hoping that at least one person might assist in the documenting of DTL, since this'll probably turn out to be a large task! The payoff might be that you'll be generously lauded in the first book on D, which Walter and I will be working on as soon as 1.0 (including DTL) looks like it's on the non-too-distant arrival. Ah, the sweet sickly smell of fame ... ;)

Cheers

Matthew


"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cefif4$nkj$1@digitaldaemon.com...
> It's, as we say in Yorkshire, as rough as a badger's arse.
>
> However, it's here, and I guess that's something at least. I can do no more for a few days, as I've spent the last
three
> on this when I should have been earning cold hard green stuff. It's going to be a tough w/e ...
>
> Notable points for anyone of an investigative nature:
>
> 1. List, Map, Stack, Queue and Vector all do "real things", and should be manifestly useful for people with real needs
> now, so long as they're happy with just foreach enumeration. Set is nothing but a shell at the moment.
> 2. Off the top of my head, only List does the range composition stuff yet. Check out test/list_test.d, which uses
> collect, and has some examples of composed select().
> 3. The lib depends on std.box, std.boxutil and std.type.traits, none of which are yet part of Phobos. In fact they may
> never be, but that's not terribly important at the moment. They can be sorted later.
> 4. There are many untrackable (or at least untracked) linker problems with simple utility templates, so you'll see
lots
> of places where the std.dtl.common.swap template is commented out and hard coded. I have no idea why the linker does
> this with in some link-units and not others that use the same templates. Something TBD.
> 5. There are no docs. You'll have to be guided from what I've posted over the last few weeks and months, until at
least
> DTL 0.1.2. :) Hopefully, if people ask smart questions, it'll help me write better docs. Just remember, there are four enumeration modes: foreach, ranges (composable foreachable thingies), interfaces (whether Object or parameterised;
both
> will be supported), and iterators (this code has not been enabled/compiled for months, so I have *no idea* what it'll do. define UseIterators at your own peril).
>
> I will check in for responses over the next few days, but I won't be able to do any more on this until late next week. Hopefully I can have isolated some nasty compiler-crash test cases and dispatched them off to big W, which will help with some aspects (notably parameterised interface enumeration, i.e. deriving from IContainer!(int), etc.).
>
> Cheers
>
> -- 
> 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)
>
> "Youth ages, Immaturity is outgrown, Ignorance can be educated, drunkeness sobered. But stupid lasts forever", Aristophenes
>
> -----------------------------------------------------
>
>
>
>

Matthew wrote:

> Hopefully, if people ask smart questions, it'll help me write better docs.

Damn! That leaves me out of the loop. Nah, there aren't any stupid questions. :)

Two suggestions, in fact:

. to make more D-like, replace "template Box(T, R = T) { class Box ..." with
"class Box(T, R = T) { ...", as mentioned in the other ng
. why don't you add opCast? "reference_type opCast() { return m_value; }". So
when you use a boxed value, you can use "v = cast(v_type) boxed_v;" instead of
"v = boxed_v.value;"

Just suggestions. BTW, the license is much better now.

-----------------------
Carlos Santander Bernal

I like them both!

Keep 'em coming. :)

"Carlos Santander B." <carlos8294@msn.com> wrote in message news:ceg3m2$103l$1@digitaldaemon.com...
> Two suggestions, in fact:
>
> . to make more D-like, replace "template Box(T, R = T) { class Box ..." with
> "class Box(T, R = T) { ...", as mentioned in the other ng
> . why don't you add opCast? "reference_type opCast() { return m_value; }". So
> when you use a boxed value, you can use "v = cast(v_type) boxed_v;" instead of
> "v = boxed_v.value;"
>
> Just suggestions. BTW, the license is much better now.
>
> -----------------------
> Carlos Santander Bernal
>
>

Matthew wrote:

> It's, as we say in Yorkshire, as rough as a badger's arse.
> 
> However, it's here, and I guess that's something at least. I can do no more for a few days, as I've spent the last three on this when I should have been earning cold hard green stuff. It's going to be a tough w/e ...
> 
> Notable points for anyone of an investigative nature:
> 
> 1. List, Map, Stack, Queue and Vector all do "real things", and should be manifestly useful for people with real needs now, so long as they're happy with just foreach enumeration. Set is nothing but a shell at the moment. 2. Off the top of my head, only List does the range composition stuff yet. Check out test/list_test.d, which uses collect, and has some examples of composed select(). 3. The lib depends on std.box, std.boxutil and std.type.traits, none of which are yet part of Phobos. In fact they may never be, but that's not terribly important at the moment. They can be sorted later. 4. There are many untrackable (or at least untracked) linker problems with simple utility templates, so you'll see lots of places where the std.dtl.common.swap template is commented out and hard coded. I have no idea why the linker does this with in some link-units and not others that use the same templates. Something TBD. 5. There are no docs. You'll have to be guided from what I've posted over the last few weeks and months, until at least DTL 0.1.2. :) Hopefully, if people ask smart questions, it'll help me write better docs. Just remember, there are four enumeration modes: foreach, ranges (composable foreachable thingies), interfaces (whether Object or parameterised; both will be supported), and iterators (this code has not been enabled/compiled for months, so I have *no idea* what it'll do. define UseIterators at your own peril).
> 
> I will check in for responses over the next few days, but I won't be able to do any more on this until late next week. Hopefully I can have isolated some nasty compiler-crash test cases and dispatched them off to big W, which will help with some aspects (notably parameterised interface enumeration, i.e. deriving from IContainer!(int), etc.).
> 
> Cheers
> 

I only scratched the surface of DTL but, as posted on the other newsgroup, I think the DTL Enumeration interface should differ from Java's. In Java that interface is "de-facto" deprecated (marking it as deprecated in the Java language sense would probably cause too many existing files to spew warnings). The simplest option is to keep the name Enumeration, since that is a pretty nice name, but use the new (well, "new" as in 5 years ago instead of 8) shorter names of hasNext() and next() instead of hasMoreElements() and nextElement(). I think Java programmers who look at D will wonder, as I did, why we are keeping Java's warts.

"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:ceiqqh$22s0$1@digitaldaemon.com...
> Matthew wrote:
>
> > It's, as we say in Yorkshire, as rough as a badger's arse.
> >
> > However, it's here, and I guess that's something at least. I can do no more for a few days, as I've spent the last three on this when I should have been earning cold hard green stuff. It's going to be a tough w/e ...
> >
> > Notable points for anyone of an investigative nature:
> >
> > 1. List, Map, Stack, Queue and Vector all do "real things", and should be manifestly useful for people with real needs now, so long as they're happy with just foreach enumeration. Set is nothing but a shell at the moment. 2. Off the top of my head, only List does the range composition stuff yet. Check out test/list_test.d, which uses collect, and has some examples of composed select(). 3. The lib depends on std.box, std.boxutil and std.type.traits, none of which are yet part of Phobos. In fact they may never be, but that's not terribly important at the moment. They can be sorted later. 4. There are many untrackable (or at least untracked) linker problems with simple utility templates, so you'll see lots of places where the std.dtl.common.swap template is commented out and hard coded. I have no idea why the linker does this with in some link-units and not others that use the same templates. Something TBD. 5. There are no docs. You'll have to be guided from what I've posted over the last few weeks and months, until at least DTL 0.1.2. :) Hopefully, if people ask smart questions, it'll help me write better docs. Just remember, there are four enumeration modes: foreach, ranges (composable foreachable thingies), interfaces (whether Object or parameterised; both will be supported), and iterators (this code has not been enabled/compiled for months, so I have *no idea* what it'll do. define UseIterators at your own peril).
> >
> > I will check in for responses over the next few days, but I won't be able to do any more on this until late next week. Hopefully I can have isolated some nasty compiler-crash test cases and dispatched them off to big W, which will help with some aspects (notably parameterised interface enumeration, i.e. deriving from IContainer!(int), etc.).
> >
> > Cheers
> >
>
> I only scratched the surface of DTL but, as posted on the other newsgroup, I think the DTL Enumeration interface should differ from Java's. In Java that interface is "de-facto" deprecated (marking it as deprecated in the Java language sense would probably cause too many existing files to spew warnings). The simplest option is to keep the name Enumeration, since that is a pretty nice name, but use the new (well, "new" as in 5 years ago instead of 8) shorter names of hasNext() and next() instead of hasMoreElements() and nextElement(). I think Java programmers who look at D will wonder, as I did, why we are keeping Java's warts.

Sure. What's there was just a proof-of-concept stab. If you want to make a specific recommendation, I'd be more than happy to listen. (Or was that it? <G>)

Finally had a chance to skim the DTL this morning on my way to work.  Looks nice so far, though I've yet to actually play with it.  Just some random thoughts I had while perusing the code:

Much of DTL uses the C++ naming scheme.  As much as I like it, stuff should be renamed to suint the D convention.

Types should be mixed case with a leading capital: size_type -> SizeType or just Size, etc.

Functions should be mixed with a leading lowercase:
pop_front -> popFront
is_open -> isOpen

traits.d: isValue is either not complete or bugged

I'm kind of torn on the leading "I" for interfaces.  I want to not like it but I can see how it would be useful.

List.clear() delinks every node.  This may help GC but is it really necessary?
I'd prefer not to have an O(N) clear if an O(1) version works just as well.

I ran across "mixes Ranges" twice as part of class inheritance lists.  Should this compile?  And if so, what does it mean? :)

Possible shortcut for categories.d:

# class _Function(I, R) : I
# {
# public:
#     alias R     return_type;
#     alias A0    argument0_type;
# }
#
# template Function(R, A0)
# {
#     alias _Function!(IFunction, R, A0) Function;
# }
#
# template Predicate(A0)
# {
#     alias _Function!(IPredicate, bool, A0) Predicate;
# }

Just means less typing.  Three cheers for templated typedefs :)

Enumerator:

perhaps rename hasMoreElements() to hasMore(), more(), or atEnd().  Rename
nextElement() to next().


Sean

Regarding a TODO in map.d:

replace: foreach(key_type key; m_elements.keys)
with: foreach(key_type key, inout value_type value; m_elements)

According to the docs on foreach, this should work.


Sean

DTL looks cool! Cleanest GP code I've ever seen.

Just one suggestion: Make the collection interfaces second class citizens. I don't get what's the big benefit of them:

Given three functions foo(), bar() and colFoo():

foo() has a list of integers of type vector!(int)

bar() accepts a list of type Vector!(int, ISequenceContainer)

Therefore bar() can delegate the call to colFoo(), which
accepts the list as an ISequenceContainer.

Now, foo() cannot efficiently pass its list of integers to bar(), although bar() expects nothing else than a list of integers!


Wouldn't it be simpler and more flexible if collection interfaces were
provided by 'wrapper' classes instead?
Mixins could be included too, so you could create your own container objects
to benefit from encapsulation.


Farmer.