dolfin team mailing list archive

["Martin Sandve Alnæs" <martinal@xxxxxxxxx>]

2008/1/23, Johan Hake <hake@xxxxxxxxx>:
> On Tuesday 22 January 2008 18:43:30 Anders Logg wrote:
> > On Tue, Jan 22, 2008 at 03:15:02PM +0100, Ola Skavhaug wrote:
> > > Anders Logg skrev den 22/01-2008 følgende:
> > > > On Tue, Jan 22, 2008 at 03:04:44PM +0100, Martin Sandve Alnæs wrote:
> > > > > I think this is definitely a "bug". (It's not a function, but a
> > > > > built-in type.)
> > > >
> > > > Agree. Suggestions?
> > >
> > > %rename(dolfin_set) dolfin::set;
> > >
> > > ??
> > >
> > > Ola
> >
> > If possible, it would be good to have the same function names in
> > Python and C++ (or I will be confused).
> >
> > Here are two options:
> >
> > A. Rename all free functions in DOLFIN to dolfin_foo. This will
> > include
> >
> >   dolfin_message
> >   dolfin_error
> >   dolfin_debug (already called this today for technical reasons)
> >
> >   dolfin_set
> >   dolfin_get
> >
> >   dolfin_init
>
> I think that these will be too cumbersome to use.
>
> > We would not touch the free functions assemble() and solve() which are
> > prominent enough not to be prefixed by "dolfin_"
> >
> > B. Don't prefix the functions and find a better name for
> > dolfin::set(). For example, we could have
> >
> >   setparm()
> >   getparm()
>
> I vote for these.
>
> I notice that pylab use setp and getp, so these are not any options.

In my opinion, "parm" is a bad short form of "parameter"...
If a "setsomething" form is to be used, "param" is better.

However, I vote for keeping "message, error, debug", and
> >   dolfin_set
> >   dolfin_get
> >   dolfin_init

since in these three cases, you do set/get global _dolfin_ parameters
and initialize _dolfin_ subsystems. Thus I think having dolfin in
their names carries more meaning in a way.

-- 
Martin