D Beginner Trying Manual Memory Management

[Laeeth Isharc via Digitalmars-d-learn]

>>> struct File { Location _location; alias _location this; ... }
>>>
>>> // group.d
>>> public import commonfg;
>>> struct File { Location _location; alias _location this; ... }
>>>
>>> // commonfg.d { ... }
>>> enum isContainer(T) = is(T: File) || is(T : Group);
>>> auto method1(T)(T obj, args) if (isContainer!T) { ... }
>>> auto method2(T)(T obj, args) if (isContainer!T) { ... }
>>>
>>> I guess two of my gripes with UFCS is (a) you really have to
>>
>>>
>>> // another hdf-specific thing here but a good example in 
>>> general is that some functions return you an id for an object 
>>> which is one of the location subtypes (e.g. it could be a 
>>> File or could be a Group depending on run-time conditions), 
>>> so it kind of feels natural to use polymorphism and classes 
>>> for that, but what would you do with the struct approach? The 
>>> only thing that comes to mind is Variant, but it's quite meh 
>>> to use in practice.
>>
>> Void unlink(File f){}
>> Void unlink(Group g){}
>>
>> For simple cases maybe one can keep it simple, and despite the 
>> Byzantine interface what one is trying to do when using HDF5 
>> is not intrinsically so complex.
> So your solution is copying and pasting the code?
>
> But now repeat that for 200 other functions and a dozen more 
> types that can be polymorphic in weirdest ways possible...

If you are simply have a few lines calling the API and the 
validation is different enough for file and group (I haven't 
written unlink yet) then why not (and move proper shared code out 
into helper functions).  The alternative is a long method with 
lots of conditions, which may be the best in some cases but may 
be harder to follow.

I do like the h5py and pytables approaches.  One doesn't need to 
bother too much with the implementation when using their library. 
  However, what I am doing is quite simple from a data perspective 
- a decent amount of it, but it is not an interesting problem 
from a theoretical perspective - just execution.  Now if you are 
higher octane as a user you may be able to see what I cannot.  
But on the other hand, the Pareto principle applies, and in my 
view a library should make it simple to do simple things.  One 
can't get there if the primary interface is a direct mapping of 
the HDF5 hierarchy, and I also think that is unnecessary with D.

But I very much appreciate your work as the final result is 
better for everyone that way, and you are evidently a much longer 
running user of D than me.  I never used C++ as it just seemed 
too ugly! and I suspect the difference in backgrounds is shaping 
perspectives.

What do you think the trickiest parts are with HDF5?  (You 
mention weird polymorphism).



Laeeth