[petsc-dev] post 3.1 reorganization of PETSc DMMG code

[Matthew Knepley]

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>