[petsc-dev] SNESGetSNESLineSearch and TSGetTSAdapt

[Jed Brown]

Matthew Knepley <knepley at gmail.com> writes:

> On Mon, Apr 15, 2013 at 8:13 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>
>> Should we change the names below too?  I guess I didn't see value in the
>> names above (basically Hungarian notation for functions) and I don't
>> think they make anything more consistent.
>>
>
> You are suggesting getting rid of the class prefix? We do consistently use
> this
> when we have different input types. I don't think it cleans up the code
> enough to
> change.

Well, TSGetTSAdapt used to be named TSGetAdapt.  It was changed in:

  commit ad6bc4219076b084d4a49a29c04a77944f238f10
  Author: Barry Smith <bsmith at mcs.anl.gov>
  Date:   Sun Dec 9 18:14:24 2012 -0600
  
      My first TS restart just 8 million other changes needed PETSc!
      TSGetAdapt() changed to TSGetTSAdapt() because it gets a TSAdapt object, not an Adapt object
      added TSAdapt binary view and load
      
      Hg-commit: c5ab7de6c480df2d7b84dc349ac7871cdc85dcbe

But this rationale does not match the more established convention used
by functions such as those below.  We still haven't released, so we
could switch back to TSGetAdapt without people hating us.

Note that SNESGetSNESLineSearch was briefly named SNESGetPetscLineSearch
(when it returned a PetscLineSearch), which doesn't match any existing
convention.

If we consider SNESGetSNESLineSearch to be more of an outlier than those
below, I would rather at least change TSGetTSAdapt back to TSGetAdapt
(i.e., no change for people following released PETSc) and perhaps also
change to SNESGetLineSearch.  If we say TSGetTSAdapt is the proper way
to name functions, we're obligated to apply that rule consistently,
which means quite a lot of changes for users (the list below is not
exhaustive).

>> MatGetMatInfo
>> MatGetISColoring
>> MatGetMatNullSpace
>> SNESGetSNESConvergedReason
>> MatGetISLocalToGlobalMapping
>> MatGetISLocalToGlobalMappingBlock (oops, 33 characters)
>> MatGetOrderingIS (?)