lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew S. Townley" <...@atownley.org>
Subject Re: [lucy-dev] Host overriding of all non-final methods
Date Thu, 03 Mar 2011 09:03:39 GMT
Hi Marvin

On 3 Mar 2011, at 03:08 a.m., Marvin Humphrey <marvin@rectangular.com> wrote:

> Greets,
> 
> There's no good reason for it, but right now only methods which are tagged as
> either "public" or "abstract" within Clownfish can be overridden from the host
> language.
> 
> This caused a problem in an application I was working on because we wanted to
> override IndexSearcher's Top_Docs() method.  Since Top_Docs() is not yet 
> public in Lucy, the attempt to override it from Perl fails silently: no
> callback is installed.  Thus, when Searcher_Hits() invokes Top_Docs() from
> C-space on our subclassed IndexSearcher, it gets the C function
> IxSearcher_top_docs() rather than the Perl subroutine top_docs() from our 
> subclass.
> 
> The fix is to allow any non-final method to be overridden, regardless of its 
> exposure.  Patch below.
> 
> 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.
> 
> 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.  
> 
> 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.

Lazy or not, I think it's better to fail silently now and then try and build better checks
into the clownfish compiler or some kind of clownlint tool later than imposing exception handling
overhead on potentially every method call (unless I'm misunderstanding the impact of option
B).

:)

ast
Mime
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message