Then we'll have a mix of notation. I find consistency in the interface highly preferrable over not having to write the () in certain special cases.
And all the old reasons for hiding data behind functions in C++ still apply. For example if size is made a member instead of a function of Vector, then we can't create uninitialized vectors, because this code will be highly confusing: v = Vector() v.size = 100 # does nothing except making the object inconsistent in other words there is no safe way to get property syntax in C++. To clarify my position: - I oppose using open members in C++ because it will lead to an inconsistent and/or unsafe interface - I oppose using properties in Python because of the work involved (i.e. I will not volunteer for this) - I oppose both because of all the code that will break (I can't imagine a code that will not break) Martin On 21 May 2013 09:43, Garth N. Wells <[email protected]> wrote: > 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
