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 <marti...@simula.no>: > 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 fenics@fenicsproject.org http://fenicsproject.org/mailman/listinfo/fenics
