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

[Dima Karpeyev]

On Mon, Apr 5, 2010 at 10:33 PM, Jed Brown <jed at 59a2.org> wrote:
> On Tue, 6 Apr 2010 03:46:37 +0200, Matthew Knepley <knepley at gmail.com> wrote:
>> I think we do. If we do not, then we should.
>
> I think the primary failure here is setting options on objects that
> can't be created until setup (typically PCSetUp).  These objects have a
> well-defined prefix so they are controllable through the options
> database, but there is no way for the user to get hold of them because
> the user lacks control at the time when they are created.  Perhaps this
> can be resolved, but it's tricky.
>
>> > > Strings are ALWAYS a bad interface.
>> >
>> > But they are generic...
>
> Some people, when confronted with an API extensibility problem think "I
> know, I'll use strings".  Now they have two problems.
>
> In particular, they now have two APIs, except that the second has no
> type checking and typically ill-defined semantics.

You can say the same about the objects and functions composed with a
given object:
being a PetscObject is a very weak type restriction (in reality, the
consumer of that object
will cast it to something else anyway).  It's even worse for
functions, and the semantics are
not controlled by the library in either case.  As it should be, in
presence of such weak type safety.

The idea here is that these hooks (PetscObjects, functions, strings)
are intended for the user
(the app), and the library API is not affected by what's on these
hooks at all.  On the other hand,
it would indeed be bad if the API calls depended on this opaque object
state defined by the
weakly typed attached crap.

Dmitry.


>
> Jed
>