Clunky and ambiguous naming of wrapped templated classes

[joeljonsson]

A quick fix might be to rename them to remove any ambiguity, e.g.,

FloatParticles -> Float32Particles
ShortParticles -> Uint16Particles

But ideally we want an interface / base class Particles which can hold data of different types. The same goes for converter and pixeldata.

[cheesema]

What about f32 and u16?

[cheesema]

On the above, did you ever try having a more generic base class, then using an interface with .astype(), and then auto datatype detection?

As currently this results in the code being prone to seg faults when you forget to manage your types.

Especially since its not super transparent in the conversion step.

[cheesema]

This is largely being solved by #52 ?

[joeljonsson]

Not really.. It makes conversion easier, but doesn't touch the class names. In answer to your previous post:

On the above, did you ever try having a more generic base class, then using an interface with .astype(), and then auto datatype detection?

This is possible, and fairly simple to implement as a python class. However, we would need another layer of wrapping around the library calls so that the ParticleData object is passed in instead of the parent class. This could be pretty neat, but requires some refactoring.

Perhaps the cleanest solution would be to just use numpy arrays, and initialize ParticleData objects internally that borrow the underlying data (similar to what we do with PixelData).