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-...@simula.no 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@fenics.org > http://www.fenics.org/mailman/listinfo/dolfin-dev _______________________________________________ DOLFIN-dev mailing list DOLFIN-dev@fenics.org http://www.fenics.org/mailman/listinfo/dolfin-dev
