[teqdruid]

Since I'm interested in getting a containers lib in Mango pretty soon (read: last week) I figured I'd start the discussion.

Since there are at least a few containers libs out there, it probably doesn't make sense to start from square one. A few possibilites to consider (if the authors consent) are:
DTL
MinTL
Indigo
Any others?

Also, what features do people feel are important to a container lib in mango? A few to consider are:
Thread-safeness
Hierarchy (including interfaces, ect...)
Any others? Those are my important points.

So, what are people's thoughts on the subject? Any opinions on the above libraries, and features?

Kris, since a containers lib is my current big stumbling block, I'd like to get a move on this. What are you current thoughts? Do you mind if I investigate this?

-John

[kris]

Go for it, John! I've got too many other things on my plate, so I'm very glad to hear you're willing to take this on.

FWIW, I'd prefer to see a class-based approach ~ a reasonably thin hierarchy, with possibly an Interface here or there to make certain things compatible (though D can sometimes have noticable overhead for interfaces).

I think thread-awareness is perhaps more important than thread-safety ~ meaning that I wouldn't want to see synchronization blocks scattered throughout the code (for performance reasons), but an optional synched version of some container would be very useful. Note that certain implementations can be both thread-safe and hi-performance: mango.cache.HashMap is such a beast, and hails from the house of Doug lea. Would be great to get a set of containers along those lines, but I think that might be expecting too much?

Again FWIW, I have a certain distaste for excessive use of Templates, useful though they are. But that's perhaps a personal issue

I haven't seen Ben's recent attempts at wrapping classes around MinTL, but that's a pretty good approach; whereas Indigo is perhaps closest to Mango in terms of general notions? DTL may never see the light of day

Adopting Ben's Locks package would be a good thing. It's a straight port of Doug Lea's mid-level utilities ~ the same ones that are in the latest release of Java. Very useful for multi-threading.

[teqdruid]

I believe we are thinking along the same lines.

Does DTL even compile with the latest DMD? If it does, I'd rather not exclude it from investigation altogether.

[kris]

Sounds good.

I'm gonna' have a go at migrating Ben's port of Doug Lea's Lock library.

[kris]

That went along without too much trouble. Got the stuff operational on Ares too.

I moved Ben's 'atomic' utilities into the mango.sys package and fixed some bugs in the assembler code within. Prof Lea's designs are really well done ~ particularly for such a grungy area of functionality ~ and Ben seems to have done a nice job adding the appropriate D'isms.

If Prof Lea has more containers along the lines of ConcurrentHashMap, that might be a good place to look. Here's a write up on why Lea's ConcurrentHashMap is the real McCoy: http://www-106.ibm.com/developerworks/java/library/j-jtp08223/

And here's a link to some of his work on other containers: http://gee.cs.oswego.edu/dl/concurrency-interest/index.html

Here's a read on thread-safety: http://www-106.ibm.com/developerworks/java/library/j-jtp09263.html

Oh; here's an important one ~ the benefits of immutability: http://www-106.ibm.com/developerworks/java/library/j-jtp02183.html

[teqdruid]

Since I haven't gotten any other input, I've looked at Indigo and MinTL, although I haven't had a chance to take a look at Ben's new class-based stuff yet. The biggest difference, to me, is that Uwe's code is more readable and better documented (sorry Ben).

As they currently both stand, they both provide some solid containers. Neither of them appear to be thread-aware (with the notable exception of the concurrent stuff in MinTL) and neither of them provide a polymorphic approach. These (in my mind) are two characteristics that make something Mango-caliber.

As such, unless MinTL's polymoric stuff is pretty good, I'd like to go ahead and start the Mango containers with the OO skeleton- interfaces and such. Once that's done, we can merrily take the various implementations from both projects (pending their author's approval) and modify them to implement our structure.

I'm also inclined to design in a manner very similar to Java's collections. That is, a set for each basic container type, all of which extend a "Container" interface. I'd also like to go a similar route with thread-awareness and create wrapper classes like Java's Collections.synchronized*() does. This is not to say that this will be the only way to create synchronized containers, but it will provide a way to wrap any container to be "thread-safe".

In terms of mutability, I don't have any thoughts. We could provide an ImmutableSet (or other container) interface, and implement it, but I'm not certain how this should fit into the hierarchy, and how it should be related to the mutable containers. I do, however, think that (in naming) mutability should be assumed for containers. In other words, I'd rather not have MutableSet- just Set, and ImmutableSet, as I believe that mutable containers are far more common. I do see the advantages of immutable containers, and would like to provide them (mostly 'cause I wanna use them.)

Your thoughts?

[kris]

As far as mutability goes, it might be sufficient to simply ensure all mutator methods are in a derived class; as in MutableList derives from List?

That way, one can specify the argument of a function to be just 'List' and the caller will thus be assured the content won't change. That approach can be very effective, but it can make a rat's nest out of an existing design; especially interfaces ~ it's something that has to be considered up-front.

- Kris

[teqdruid]

[kris]

[teqdruid]

[kris]

Container? Collection? I don't care

Regarding the covariance issue, it seems to me you might do without interfaces for the most part. I mean, Collection could be an abstract base, and everything else could (on the face of it) be a concrete? What I'm getting at is that Interfaces might be relegated to things like ISortable, or IComparable? You know ~ the "bolt-on" things that you can't do cleanly with a single-object hierarchy?

If that were the case, I think it would be perfectly acceptable to avoid an Interface altogether at the root level. Would probably execute quite a bit faster too! ~ ignoring the vTable, code for converting an object handle into an interface argument is not pretty at all: the two "unnecessary" jmp's executed, just in case the object handle is null, will put perhaps as many bubbles in the CPU pipeline as a scuba tank could. This is arguably OK for large-grained function calls, but totally bogus for the small ones. Of course, it could be that interfaces don't get passed to Containers as method arguments ~ if so, this would not be of concern.

If you went without an Interface at the root, that could mean more difficulty in adopting other, existing, containers. However, given the number of containers we're likely talking about, and the nature of them, I would argue that's not such a big problem ~ even if the covariance concern did not exist. The same might be said for a deep layer of abstract classes. I'm seriously thinking of trying to remove one or two interfaces from the Mango IO layer ~ the only thing stopping me are concerns over backward compatability.

I guess what I'm saying is this: I'm not sure there is actually enough true and tangible value in using interfaces to the degree that's been suggested? Sometimes it's better to just back away a little; kinda like playing less notes in a solo, in order to allow other dynamics a chance to shine through

[teqdruid]

OK, so I've been writing an abstract class hierarchy (and started on some basic implementations to test it all) and I've been thinking about the naming and hierarchy for mutable/immutable stuff. Here's my current line of thinking:

[Stefan]

[kris]

[teqdruid]