lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Kurz <>
Subject Re: [lucy-dev] Host overriding of all non-final methods
Date Sat, 05 Mar 2011 07:27:59 GMT
On Wed, Mar 2, 2011 at 10:30 PM, Marvin Humphrey <> wrote:
> Arguably, we don't even need the "final" keyword.  We'd should benchmark to
> confirm my recollection about the performance implications, but I'll bet we
> could remove it with no immediate impact on Lucy.

I'd suggest this as the cleanest solution.  Intuitively, I'd think
that the benefit of 'final' would be very small, such that if one
really cares about performance one should inline the function call
completely and not worry about saving a single dereference.

>> 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?
> Haha, that's true.  When code can be verified via unit tests, I prefer that,
> since it stores the noise out of band in a unit test file.  I'm not a fan of
> the way asserts pollute the main code base.

Your unit tests are great, but assert() let's you catch errors while
still programming defensively. Take the "!!foo == !!bar" example from
a couple days ago.   You fix the problem with "!!", and presumably
have unit tests that check that you fix it, but now you never get a
warning that something has gone awry.  With only unit tests, you have
to choose whether to report the error or try your best to handle it.
Assert (running only for the debug build) let's you do both of these
--- cry out loudly that an assumption has been broken when running
debug, and do what you can to carry on in production.   In some ways,
the key is not just assert(), but rather the existence of a debug
build with appropriate scaffolding.

If you choose to keep 'final', I think assert() is really the right
tool here, too.  You don't want the production system to fail because
a programmer is trying to override something non-overridable, but you
need to warn the user somehow.  Unit tests and asserts are not a "belt
and suspenders" sort of redundancy.  Rather it's more of "shirt and
pants" thing.  Both have their place socially, and there are
situations one, the other, or neither are needed.  But rarely do you
find yourself required to have at least one, but are allowed to choose
which one that is.   But it's your house/project, and you're welcome
to set your own dress code, even if it is a bit pedantic to test the
limits of "Shirt and Shoes Required" by not wearing any pants.  (long

Nathan Kurz

View raw message