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