On 21 May 2013 07:31, Johan Hake <[email protected]> wrote: > I did not say it as clear as Martin, but my perspectives are pretty much > the same. >
I agree. One point: if we decide that the syntax without the () is generally preferred, we can allow direct access to member data (when appropriate) in new classes in the C++ interface. The syntax would then pass automatically to the Python wrappers. Garth > Johan > > On 05/21/2013 08:07 AM, Martin Sandve Alnæs wrote: >> 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" <[email protected] >> <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> http://fenicsproject.org/mailman/listinfo/fenics >> > > _______________________________________________ > fenics mailing list > [email protected] > http://fenicsproject.org/mailman/listinfo/fenics _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
