On Thursday, 24 August 2017 at 18:16:21 UTC, jmh530 wrote:
I think at one point I had actually suggested that dstats or
something be re-written in a Julia-like way (before I realized
how much work that would be!). It looks very pretty.
Thanks. I think most of that is down to D's nice syntax and how
it easily and clearly emulates Julia. I think that there is
certainly more to say on this especially around strategies of how
represent concrete types. David Gileadi's point about UDAs could
add an interesting spin on things, and Ali's point on dynamic
Nevertheless, you might be re-inventing the wheel a bit if you
want to build a whole library in this style.
True. I have found a couple of projects that fresh targets that I
am working on and writing code in this style.
My recommendation would be to write a front-end for the
dstats.distrib and dstats.random submodules in this style. That
way you won't need to re-write all the functions, you can just
call ones from dstats that have already been tested.
True code reuse is important, especially when you want to get
something working quickly.
More generally, I prefer the structs because they don't rely on
the garbage collector, but the class/interface version is
Aha! I was wandering why I see people avoid classes even when
using them is clearly the best way to represent their objects.
For some reason it never occurred to me that they where just
trying to avoid the GC. I just thought they didn't want to use
Atila's concepts library has implements, which you might find
helpful. I have gently nudged him to work on something that
also can tell if a type is a subtype of another type more
generally (like a struct being a subtype of another struct). I
think this would really be a good use case for that
I was thinking about this article for some time, it was Atila's
(https://atilanevesoncode.wordpress.com/2017/08/23/on-the-novelty-factor-of-compile-time-duck-typing/) that was a trigger for me writing it.