dcollections 1.0 and 2.0a beta released

Michel Fortin michel.fortin at michelf.com
Wed May 19 19:48:33 PDT 2010


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
}

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.

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

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?


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/



More information about the Digitalmars-d-announce mailing list