Barry Smith <[email protected]> writes: > I don’t see how you are going to manage making them optional but > allowing them to be passed around (since C has no optional > arguments). If we want that route then I think we need to bit the > bullet and just attach a PetscOptions thing to a PetscObject and > if it has one it uses it to look for options, otherwise it looks > in the “global” one. I don’t see how some PETSc routines can take > a PetscOptions argument and others don’t.
I was thinking of making an entire set of functions that take an explicit argument, then implementing the current interface in terms of those (getting the thread-local object and passing it in). The idea is to allow people to use the current interface because it's convenient, while moving PETSc's own implementation to explicitly pass the options object. It's certainly not a trivial amount of work, but if we have to overhaul it anyway, I'd be in favor of providing an interface where the database is an explicit parameter. The more disrupting thing would be to change all the functions to take an explicit argument, but allow NULL, which means "get it from thread-local". That would require changing all existing code and creates one more argument to keep track of.
pgpzKEVoNpcxF.pgp
Description: PGP signature
