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
