bearophile wrote:
> The serialization example, page 21 of the slides, is interesting. The API/syntax they use doesn't look too much readable, but such functionality is probably quite useful in certain kinds of D programs. So D may enjoy a little more handy ways to manage its reflective information. Avoiding most of such serialization hack.
I'd be more than happy to see some wider support from D in this regard, but for now we're stuck with D1 and such hacks ;)
> The following code is cleaned/improved from the OMG:
> http://team0xf.com:8080/omg/file/aca17fefefc1/core/Algebra.d> But does it work? Strings turns up being "summable", but if you actually add them you get an "Array operations not implemented" error:
Ah well, SFINAE fails here :P No sane person will be using these for strings anyway ;) The traits are used mostly to be inline documentation about what features the user defined type must provide.
--
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode

Tom S:
>I'd be more than happy to see some wider support from D in this regard,<
If no one discusses about this, things aren't going to improve. I'll post something related to this to the main D newsgroup soon.
>Ah well, SFINAE fails here :P<
But the interesting question is why does it fail? It seems a bug of DMD, not a bug in that code.
>No sane person will be using these for strings anyway ;) The traits are used mostly to be inline documentation <about what features the user defined type must provide.<
It looks like generic library code, so you can't assume a sane person, so I suggest you to put unittests, that contain such case too. You may even add a static if to work around such "common" bug (I know, isSummable() is absent from your code):
template isSummable(T) {
// BUG: IsArray!(T) is added to patch a possible bug of DMD v.1.036
const bool isSummable = !IsArray!(T) && is(typeof(T.init + T.init));
}
template isRingType(T) {
const bool isRingType = isSummable!(T) &&
is(typeof(T.init - T.init)) &&
is(typeof(T.init * T.init));
}
template isFieldType(T) {
const bool isFieldType = isRingType!(T) && is(typeof(T.init / T.init));
}
Writing very reliable "library" code (bulletproof, if possible) avoids you bugs later in all the code that uses that library code. Adding lot of unittests (covering even weird corner cases) to every function, class and template helps.
Bye,
bearophile

bearophile wrote:
> Writing very reliable "library" code (bulletproof, if possible) avoids you bugs later in all the code that uses that library code. Adding lot of unittests (covering even weird corner cases) to every function, class and template helps.
It is meant to be reliable, but not paranoid. You assume that the coder has too much time on his hands :P I see no reason anyone would want to create a 3d vector of strings for use with OMG.
--
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode