Lets stick with FooView, it's clear about ownership, works well with tab completion, and avoids name clashes.
A ufl type FunctionView would actually be an operator with two operands: a Function and a slice/index. The dolfin FunctionView would inherit from cpp.FunctionView and ufl.FunctionView. Overloading ufl operator types in dolfin would be a first, so there may be pitfalls, but it looks fairly clean to me. Martin On 25 February 2015 at 11:34, Garth N. Wells <[email protected]> wrote: > On Wed, Feb 25, 2015 at 10:27 AM, Martin Sandve Alnæs > <[email protected]> wrote: > > 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) > > Yes, clumsy. > > > 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) > > > > I think I prefer View because it's more explicit in terms of > ownership. 'Sub' is nice, but one can still wonder over ownership, but > I guess would be ok if we're consistent. > > I'm not sure SubMesh would be natural in the case that the view is > into a different topological dimension, e.g. a view into the boundary > of a Mesh. > > > 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). > > > > Yes, sorting out 'split' would be nice and we should take this into > account in any design. > > Garth > > > 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
