I find the work/benefit ratio for this way too high. I wont do this for ufl and related code, I have better things to do. This is a major undertaking which breaks lots of code and will introduce bugs all over until it matures.
Martin Den 20. mai 2013 23:05 skrev "Johan Hake" <hake....@gmail.com> følgende: > [snip] > > I have no strong opinion on the issue Garth has on C++ member data > instead of get/set methods. I might just add that it is probably doable > but not straight forward to map access to a public std::map object. > > Now we just return a copy of the map as a python dict. As it is returned > from a method and it makes sense that altering the dict does not alter > the stored private data. If it would become a public attribute it is not > obvious how we should map access to that object to Python, though. > > > I'm not keen on additions that diverge the C++ and Python > > interfaces, or changes that require more Swig glue or Python wrappers > > than are absolutely necessary. It more than doubles the work (2 x > > testing, 2 x documentation, plus making sure both interfaces do the > > same thing). > > > > Garth > > > > > > I think this is rather weak divergence: it's on the level of Python > > syntax looking different from C++ syntax. If I understand the swig > > process correctly (and I may not), this involves a change to the > > recipe for generating code, rather than more wrappers. > > I agree that the divergence in the resulting code is weak. The actual > code that needs to be written in the SWIG layer should also be pretty > easy, but it needs to be done for each methods which should be mapped. > There are powerful regexp tools in SWIG to help create a recipe for > similar such methods->property code snippets, but I am afraid we need to > go through the interface and generate these code snippets for most > methods manually. > > >> My swig knowledge is essentially non-existent. But this > >> conversation appears to indicate how to do it: > >> > >> > http://swig.10945.n7.nabble.com/Extending-Python-proxy-classes- > with-decorators-td12347.html > > > > Johan would probably be the person to comment on this. > > > > You might not want to go that route, but another option is leaving > > the SWIG layer untouched and monkey patching / subclassing the SWIG > > generated classes in dolfin.cpp and add @property decorators in > > there. > > Depending on what the method we map, either one of these approaches > could work. The bottom line, though, is that it has to be done more or > less manually (see comment above), which in my perspective, shift the > manual work from David to me... > > Johan > > _______________________________________________ > fenics mailing list > fenics@fenicsproject.org > http://fenicsproject.org/mailman/listinfo/fenics >
_______________________________________________ fenics mailing list fenics@fenicsproject.org http://fenicsproject.org/mailman/listinfo/fenics
