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. 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.
> 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
