The issue of functions taking Decorator objects, or Decorators objects as arguments vs Particle* and Particles keeps coming up. Mostly we currently are going for Decorator objects and Particles the moment which is reasonably practical, but odd. Taking decorators makes the docs better (since it is clear what is expected from the particles), but then you have to convert things back and forth everywhere.
One solution for this on the C++ side would be to: - write all methods to take Decorator objects and Decorators. This makes the docs nice and doesn't require duplicating methods - allow implicit conversions from Particle* to Decorator objects (I currently disallowed it) - allow implicit conversions from Particles to Decorators (by making Decorators be something other than std::vector, which is easy enough)
Ben, can such be made to work on the python side too via typemaps? I had looked at doing implicit conversions at some point and couldn't quite figure out how to make it work.
Daniel Russel wrote: > The issue of functions taking Decorator objects, or Decorators objects > as arguments vs Particle* and Particles keeps coming up. Mostly we > currently are going for Decorator objects and Particles the moment which > is reasonably practical, but odd. Taking decorators makes the docs > better (since it is clear what is expected from the particles), but then > you have to convert things back and forth everywhere. > > One solution for this on the C++ side would be to: > - write all methods to take Decorator objects and Decorators. This makes > the docs nice and doesn't require duplicating methods > - allow implicit conversions from Particle* to Decorator objects (I > currently disallowed it) > - allow implicit conversions from Particles to Decorators (by making > Decorators be something other than std::vector, which is easy enough)
Sounds reasonable to me. I am a little concerned about the number of classes, but I guess it's only one extra class per decorator which isn't too bad.
> Ben, can such be made to work on the python side too via typemaps? I had > looked at doing implicit conversions at some point and couldn't quite > figure out how to make it work.
In principle if it works in C++ it should work automatically in Python - SWIG usually does a reasonable job at figuring out which types can be cast to others. If not, we can certainly fix it so that it does work.
Ben
> Sounds reasonable to me. I am a little concerned about the number of > classes, but I guess it's only one extra class per decorator which > isn't > too bad. We had many of those classes anyway as XYZs sort of classes were sporadically defined. So it doesn't really add much. The class definitions are more complicated though.
> >> Ben, can such be made to work on the python side too via typemaps? >> I had >> looked at doing implicit conversions at some point and couldn't quite >> figure out how to make it work. > > In principle if it works in C++ it should work automatically in > Python - > SWIG usually does a reasonable job at figuring out which types can be > cast to others. If not, we can certainly fix it so that it does work. Swig doesn't handle conversion operators (ie Decorator::operator Particle*()). We should be able to do the same with typemaps, but not all of the modules have the swig type info for Decorator and so the code to check if something is a decorator and, if so, cast it to a particle, doesn't compile.
participants (2)
-
Ben Webb -
Daniel Russel