dcollections 1.0 and 2.0a beta released

[Andrei Alexandrescu]

On 05/19/2010 09:48 PM, Michel Fortin wrote:
> On 2010-05-19 19:01:51 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> said:
>
>> I wrote a solution to the problem in native D. It goes like this:
>>
>> alias Container!(int, addable | purgeable) Messerschmidt;
>>
>> void messWith(Messerschmidt i) {
>> ... use i's capabilities to add and purge ...
>> }
>
> Are you sure this is necessary? I'm wondering how the above is different
> from:
>
> void messWith(C)(C i) if (IsAddable!C && IsPurgeable!C) {
> ... use i's capabilities to add and purge
> }

It's different in that messWith is a type-parameterized function (aka a 
template in C++) with the known tradeoffs: multiple instantiations, risk 
of code bloating, but good speed most of the time. Add to that that some 
people aren't comfortable with those.

> where IsAddable just checks for an 'add' function and IsPurgeable checks
> for a 'purge' function. Obviously, one is a template and the other
> isn't. I'd expect the template function to be more performant since it
> doesn't require an indirection to call into the container. Is the need
> for runtime-swappable containers really common enough to justify adding
> it to the standard library? Won't adding this encourage people to use it
> without realizing the downside in performance and failed optimization
> opportunities because of the hidden dynamic dispatch? It's a quite nice
> idea, but I don't like the tradeoff.

These arguments are in line with mine. I tried above to convey that the 
situation is not all-win.

> This criticism is valid for containers implementing interfaces too. In
> my first Java programs, I was always declaring variables as the List
> interface, then instantiating an ArrayList for them, thinking it'd make
> things more generic and easier to change later. Generic sometime is
> good, but if you do that with containers in D you're in for an important
> performance drop. Personally, I'd scrap anything that's not made of
> static calls (final functions in a class are fine) so people can't
> easily make these kind of mistakes (and then believe D is slow).

By the way, I dislike the name ArrayList. Is it just me, or "list" is 
most often associated with "linked list" in computer lingo? So when I 
see "ArrayList" it looks like an oxymoron. Steve, could I impose on you 
to rename ArrayList simply Array?

> Also, addable and purgeable above being or'ed constants makes the system
> difficult to scale to new concepts. The template predicates on the other
> hand are infinitely extendable: if my containers have 'commit' and
> 'rollback' functions, I can define IsTransactional to check for the
> presence of the functions and make some algorithms that benefits from
> this. In fact, this can apply to anything, not just containers. Range
> are already using this pattern. Wouldn't it make things easier to learn
> if we could just reuse the same principle with containers?

Nice arguments!


Andrei