>> I see, thanks! :) I've started liking structs more and more
>> recently as well and been pondering on how to convert a
>> class-based code that looks like this (only the base class
>> has any data):
> it's hard to tell by brief description. but having multiple
> inheritance
> immediately rings an alarm ring for me. something is
> very-very-very
> wrong if you need to have a winged whale. ;-)
A real-world example:
http://www.hdfgroup.org/HDF5/doc/cpplus_RM/hierarchy.html
H5::File is both an H5::Location and H5::CommonFG (but not an
H5::Object)
H5::Group is both an H5::Object (subclass of H5::Location) and
H5::CommonFG
H5::Dataset is an H5::Object
i see something named "CommonFG" here, which seems to good
thing to
move out of hierarchy altogether.
bwah, i don't even sure that given hierarchy is good for D. C++
has no
UFCS, and it's incredibly hard to check if some entity has some
methods/properties in C++, so they have no other choice than to
work
around that limitations. it may be worthful to redesign the
whole thing
for D, exploiting D shiny UFCS and metaprogramming features.
and,
maybe, moving some things to interfaces too.
I just finished reading aldanor's blog, so I know he is slightly
allergic to naked functions and prefers classes ;)
With Ketmar, I very much agree (predominantly as a user of HDF5
and less so as an inexperienced D programmr writing a wrapper for
it). It's a pain to figure out just how to do simple things
until you know the H5 library. You have to create an object for
file permissions before you even get started, then similarly for
the data series (datasets) within, another for the dimensions of
the array, etc etc - that doesn't fit with the intrinsic nature
of the domain.
There is a more general question of bindings/wrappers - preserve
the original structure and naming so existing code can be ported,
or write a wrapper that makes it easy for the user to accomplish
his objectives. It seems like for the bindings preserving the
library structure is fine, but for the wrapper one might as well
make things easy.
Eg here https://gist.github.com/Laeeth/9637233db41a11a9d1f4
line 146. (sorry for duplication and messiness of code, which I
don't claim to be perfectly written - I wanted to try something
quickly and have not yet tidied up).
So rather than navigate the Byzantine hierarchy, one can just do
something like this (which will take a struct of PriceBar -
date,open,high,low,close - and put it in your desired dataset and
file, appending or overwriting as you prefer).
dumpDataSpaceVector!PriceBar(file,ticker,array(priceBars[ticker]),DumpMode.truncate);
which is closer to h5py in Python. (It uses reflection to figure
out the contents of a non-nested struct, but won't yet cope with
arrays and nested structs inside). And of course a full wrapper
might be a bit more complicated, but I truly think one can do
better than mapping the HDF5 hierarchy one for one.
Laeeth.
