On Sat, Jan 5, 2013 at 8:49 PM, Tim Tautges <tautges at engr.wisc.edu> wrote:
> Too late to matter, but I wonder why there's such aversion to longer > names. Going from DMComplex to DMPlex goes from misleading to > neutral/useless. If you had to field questions about DMComplex, I don't > think DMPlex is going to get rid of those questions much. To me, > DMCellComplex is the clear choice, or if you just can't bear the extra few > characters, then DMMesh would be almost as good. There was/is a DMMesh that DMPlex will eventually replace. "Mesh" is an extremely generic and overloaded name, but DMPlex is really one (quite general) mesh-related interface. It seems like every project has a different idea about what the "mesh" is responsible for, so I think that name is best avoided. One reason for not-too-long names is that C [1] only guarantees significance in the first 31 characters of an external identifier. Using a long prefix reduces the number of meaningful characters left. PETSc has quite few user-visible classes and we consider DMPlex to be a building block for more "helpful"/specific DMs. These can usually be moderately thin layers containing a DMPlex. For example, we're using DMPlex in a finite volume CFD/heat transfer project and in PyLith (finite elements with internal faults). It's important that the name be unique and distinctive, but not that the name be a stand-alone explanation of the component. [1] Yes, C++ supports much longer identifiers (namespaces and argument types are all mangled in), though this slows down the linker and dynamic loader. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130105/487334b0/attachment.html>
