Why would you attach an option instead of having an equiv API call? Strings are ALWAYS a bad interface.
Matt On Fri, Apr 2, 2010 at 9:29 PM, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote: > On a somewhat related note: would it make sense to have the functionality > to > attach options or just character strings to PetscObjects? > We have ways of attaching reals, ints and arrays > thereof to objects, but not character strings or options (named strings). > I would find it convenient in various situations. > It would also mirror the way we are able to compose named functions or > PetscObjects > with a given PetscObject. > > Dmitry. > > On Fri, Apr 2, 2010 at 6:33 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > > > I think this is a fine idea and have no problem with someone > implementing > > it. > > > > Barry > > > > On Mar 21, 2010, at 4:04 AM, Jed Brown wrote: > > > >> > >> > >> As a separate issue, when talking about bigger multiphysics problems, I > >> would really like namespaced options. This could be as quick-and-dirty > >> as > >> > >> -prefix_push something_ -other -options -prefix_pop > >> > >> which would mean > >> > >> -something_other -something_options > >> > >> In particular, this would have to work with > >> > >> -prefix_push fieldsplit_physics1_ -options_file physics1-solver > >> -prefix_pop > >> > >> where everything in 'physics1-solver' would be under this prefix. > >> Alternatively (or additionally), a parser for yaml options would allow > >> this composition. > >> > >> Jed > > > > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100403/2fcd6f8c/attachment.html>