I support a consistent design pattern like this. I suggest using a consistent naming convention: SubFunctionView and SubMeshView (both prefix and postfix seems overkill to me) or FunctionView and MeshView (advantage of tab completion from "Function<tab>") or SubFunction and SubMesh (language wise I prefer these names but that's impractical because of the legacy implementations)
At least FunctionView and MeshView should be mirrored in UFL abstractions. I don't think FunctionSpaceView needs a symbolic representative. A UFL type matching FunctionView could make a unified split() possible (I've mentioned this in some issue somewhere). Martin On 25 February 2015 at 11:04, Garth N. Wells <[email protected]> wrote: > We have some objects in DOLFIN that can contain data or can be a view > into another object, e.g. DofMap, FunctionSpace, Function. It's often > not clear what is what, and it tends to complicate the code for > classes that can either own data or provide a view. > > We've settled on adding a MeshView class, and it would nice to extend > this further to other classes and have, for example, DofMapView, > SubFunctionView, SubSpaceView. Objects that own data could be created > from views. For example, in place of the > Function.split(deepcopy=False) functionality, we could have > > # Mixed function > W = Function(V) > > # u and p a SubFunctionViews into W > u = W.sub_function(0) > p = W.sub_function(1) > > # u and p are now Function objects that own their data > u = Function(u) > p = Function(p) > > Thoughts on separating out objects that own data and objects that provide > views? > > Garth > _______________________________________________ > fenics mailing list > [email protected] > http://fenicsproject.org/mailman/listinfo/fenics >
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
