On Wed, Mar 2, 2011 at 10:30 PM, Marvin Humphrey <[email protected]> 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 day) Nathan Kurz [email protected]
