lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Kurz <n...@verse.com>
Subject Re: [lucy-dev] Host overriding of all non-final methods
Date Thu, 03 Mar 2011 05:28:07 GMT
On Wed, Mar 2, 2011 at 7:08 PM, Marvin Humphrey <marvin@rectangular.com> wrote:
> For "final" methods, we have two options.  We can fail silently, as we do now.
> In this case, there will be different behavior when a method is invoked from
> the host (the illegal host override method fires) vs. when it is invoked from
> within the Lucy core (the "final" method definition fires).
>
> The other option is to throw an exception at runtime when an attempt to
> override a final method is detected.  Dynamic VTable objects are built lazily,
> so the error would occur the first time the constructor for the problematic
> class gets invoked.

Orient me for a moment:  this would have to be caught in the host
language, and would need to be written this way for every language
that there are bindings?  Or is there somewhere that this could be
caught by Lucy core?  And there aren't many final methods are there?
Only on extremely performance sensitive paths?

> The rationale for this change is that method overrides should work the same way
> for both C-based classes and host-based classes: non-final methods should be
> overridable from both C and the host.  There are no public API changes because
> every public non-final method was already overridable; only non-public methods
> will get a behavior change.

Yes.

> Right this moment I'm feeling lazy, so inertia is favoring the first option for
> final methods, "fail silently." :)  Failing at runtime when illegal method
> overriding from the host is detected isn't as friendly as failing at compile
> time when an illegal override is found in a .cfh Clownfish header file, though.

That seems like the wrong kind of lazy. :)  I think the right kind of
lazy is to solve it once by brute force:  ASSERT(! $method->final).
But since true macros are hard in Perl, I'd be happy with adding an
'if DEBUG' to that so that it can get optimized away at compile if one
wants it to be.  But you never really got on the ASSERT train, did
you?

Nathan Kurz
nate@verse.com

Mime
View raw message