On Apr 2, 2010, at 9:29 PM, Dmitry Karpeev 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.
I cannot image why anyone would do this :-). But I think having the exact same support that we have for int, real etc for char* would be fine, since it doesn't introduce any additional complexity to the design. Can it be done in the same way? Barry > 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 >> >>