From: Roy S. <roy...@ic...> - 2009-04-21 21:15:35
|
On Tue, 21 Apr 2009, John Peterson wrote: > On Tue, Apr 21, 2009 at 3:21 PM, Roy Stogner <roy...@ic...> wrote: >> I don't like >> the idea of two additional arguments that we have to add to every >> function that generates a mesh. > > Well... neither do I but he's using default arguments, right? It's not API backwards compatibility I'm worried about - Derek's patch did look backwards compatible. It's API simplicity. Derek added those default_arguments to build_cube. And presumably in build_line/build_square. I'll bet not build_delaunay_square. Either way, do we add the same default arguments to build_sphere? TriangleInterface::triangulate()? Mesh::read()? We've got lots of places where we generate meshes that will default to subdomain ids 0, boundary ids 0. So we need a convenient way to change those ids. A separate function is the most flexible way. And if we have a separate function with a clean enough API, there's no reason to change all the stuff that might precede it from functionA(argsA) to functionA(argsA, then_do_function_B=true). Also: this was all prompted by the discovery that Exodus doesn't allow 0 as a valid id? What if we pick the largest valid id they do support and map 0 to/from that? It's kind of a hack, but then most users would be able to use Exodus IO on arbitrary meshes without changing their code at all. --- Roy |