It's impossible to be entirely consistent from all perspectives because of the close marriage of ufl and dolfin through multiple inheritance, so I've made everything functions outside of the ufl.Expr type hierarchy.
So e.g. the new ufl.FunctionSpace has a .ufl_domain(), .ufl_element(), and the ufl.Mesh has a .ufl_cell(), .ufl_coordinate_element(). Martin On 1 September 2015 at 10:40, Anders Logg <[email protected]> wrote: > I don't think it's a problem if the ufl_foo stuff (UFL) are properties and > the foo() stuff (DOLFIN) are functions. It's still consistent. > > Also, the ufl_cell() and ufl_element() functions are relatively low level > so backwards compatibility is less important in these cases. > > -- > Anders > > > fre 21 aug. 2015 kl 15:27 skrev Martin Sandve Alnæs <[email protected]>: > >> I'm working on preparing for the ufl.Domain class to become a ufl.Mesh >> class that dolfin.Mesh will inherit from. This involves renaming some >> methods on the ufl side to avoid name collisions. In that regard I wish for >> some feedback from the other devs and users. >> >> In the ufl.Expr class hierarchy I've previously introduced naming schemes >> where methods and attributes include 'ufl_' in the name. This makes life >> easier because e.g. dolfin.Function and dolfin.Expression inherit from >> ufl.Coefficient which is an ufl.Expr subclass. I plan to continue along >> this path now in the new ufl.Mesh. >> >> In addition, during profiling and optimization of ufl and the form >> compilers I changed several methods from ufl.Expr to be properties, i.e. >> "expr.ufl_shape" instead of the old "expr.shape()". For consistency within >> UFL I halfway want to continue along this path now in the new ufl.Mesh, but >> I'm less sure for a couple of reasons. >> >> One reason to avoid properties is the existing methods >> "dolfin_mesh.ufl_cell()" and "dolfin_function_space.ufl_element()" which >> can't be changed to properties without breaking backwards compatibility. >> >> Another reason to avoid properties is consistency within the dolfin >> interface: function style accessors is the norm in dolfin. >> >> There will also be a new class ufl.FunctionSpace which >> dolfin.FunctionSpace will inherit from, resulting in equivalent issues. >> >> Does anyone have opinions on this? >> >> Martin >> >
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
