dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Nov 04, 2009 at 02:52:38PM +0000, Garth N. Wells wrote:
>
>
> 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.

I actually made an attempt to fix this some time ago by making the
eval() function virtual in Function and using some tricks that allowed
the function class to check in the constructor that the eval function
had not been overloaded by calling it with some special secret
arguments (magic numbers) that return a secret result (another magic
number). I reverted the changes since it became too involved.

--
Anders

Attachment: signature.asc
Description: Digital signature