dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

Anders Logg wrote:
> On Thu, Nov 05, 2009 at 12:14:36AM +0100, Marie Rognes wrote:
> > Anders Logg wrote:
> > > On Wed, Nov 04, 2009 at 01:10:17PM +0100, Johan Hake wrote:
> > >
> > > > On Wednesday 04 November 2009 09:37:55 Garth N. Wells wrote:
> > > >
> > > > > kent-and@xxxxxxxxx wrote:
> > > > >
> > > > > > Hi, I am very happy with the  Expression, but old code like
> > > > > >
> > > > > > class Dabla(Function):
> > > > > >     def eval(...)
> > > > > >
> > > > > > still works.
> > > > > >
> > > > > > The only problem is that the function is zero even though eval is
> > > > > > implemented. Is it
> > > > > > possible to turn this old code into an error?
> > > > > In C++, no. There is no mechanism in C++ to prevent a user overloading
> > > > > or hiding a member function.
> > > > In Python, using meta classes, yes.
> > > >
> > > > This is a nice exercise for those of you who want to get to know meta classes
> > > > in Python. ;) If and when I have time I can fix this. (Heading for the states
> > > > next Tuesday)
> > > >
> > > > Should we allow sub-classing of Function, but not overloading of eval?
> > > We could start by disallowing subclassing the Function class and then
> > > if a time comes when someone wants to subclass it, we can rethink it.
> >
> > Nooo! (Someone(tm) wants to subclass it already.)
>
> ok, so let's rethink this. :-)
>
> Is it worth the effort to disallow overload of eval?

I don't think that it's possible. I searched the web on this a few weeks 
back and came to the conclusion that it's simply not possible. 
Function::eval is not virtual, which is a hint. The only other step is 
to put an unambiguous comment in the Function.h that you overload eval 
at your peril.

Garth

> --
> Anders
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev