On 21 May 2013 10:23, Garth N. Wells <[email protected]> wrote: > On 21 May 2013 09:00, Martin Sandve Alnæs <[email protected]> wrote: > > 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. > > > > The question is applicable to cases in which we presently have: > > const Foo& foo() const { return _foo; } > Foo& foo() { return _foo; } > > This does not hide data.
True, and it gives the misleading impression of data hiding. My open yes/no question is do we wish to > continue with the above design in new code, or allow direct access? > Safety is not an issue because data should still be hidden when > necessary. It's a style question. I'm more-or-less indifferent. I mainly think it's a bad priority of developer resources. Martin > > 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++. > > > > I used this as an example earlier in the thread where access via a > function is appropriate. In addition, the above code would lead me to > believe that there is no function call sitting behind 'v.size', which > is generally false. > > Garth > > > 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
