2008/1/23, Johan Hake <[EMAIL PROTECTED]>: > 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 _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
