[petsc-dev] Nonblocking consensus and alternative "freespace" interface

[Matthew Knepley]

On Mon, Jan 7, 2013 at 5:42 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
> On Jan 7, 2013, at 5:28 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>
> > On Mon, Jan 7, 2013 at 3:29 PM, Matthew Knepley <knepley at gmail.com>
> wrote:
> > The PetscOptions and PetscInfo functions are examples where we used
> _Private to
> > indicate a lower level interface, rather than one that was truly file
> scope. I guess we
> > need two different specifiers.
> >
> > Most of these are in matimpl.h and vecimpl.h. They should perhaps be
> called _Internal since they are shared inside PETSc, but not public. We
> should also change them from PETSC_EXTERN so that we can set
> visibility=hidden to prevent users from calling them through shared
> libraries. ;-)
>
>    I have no problem making them _Internal instead of _Private if that is
> clearer. And making them not PETSC_EXTERN
>
> >
> > I don't have a problem with non-namespaced functions at file local scope,
>
>     I do have a problem with them, because I read code I haven't seen
> before (that Jed or someone who copied Jed wrote) that looks like
>
>      PetscCoolClassAFunction(PetscSomething, ….) {
>        …..
>        PetscStrcpy().
>        SomenameofSomething().
>        ISCreate…()
>      }
>
>      and I don't know if SomenameofSomething is private to this file or
> from some other package. (note many other packages don't namespace so I
> cannot tell if it is some other package). This interrupts the flow of the
> understanding of the code so I need to restart (having to jump to somewhere
> else in the file to see if SomenameofSomething() is in the file and a local
> utility. I would prefer
>
>      PetscCoolClassAFunction(PetscSomething, ….) {
>        …..
>        PetscStrcpy().
>        PetscCoolClassSomething_Static().
>        ISCreate…()
>      }
>
> now I immediately know it is a utility function associated with the
> PetscCoolClass and it is also static (so private to the file). I can keep
> on reading.
>
> Just making up random names (no mater how local) is not good literate
> programming :-)
>
> So we are proposing utility functions in PETSc NOT for external users are
> PetscClassFunction_Internal() and for static functions in a file are
> PetscClassFunction_Static()?
>

I would prefer _Internal and _Private just because I think it sounds better.

   Matt


>   Barry
>
> Yes I realize the static is redundant with the declaration of the function
> but I am not reading the declaration I am reading the use and don't want to
> interupt the flow by jumping around.
>
>
>
>
>
>
> > they just have to be renamed if they are ever referenced from elsewhere.
>
>


-- 
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/20130107/ba43beb4/attachment.html>