On 21/05/2015 02:13, rectang wrote:
commit 596d282770eb92281190ff7a9158a478ef8cf55a Author: Marvin Humphrey <[email protected]> Date: 2015-05-20T23:40:56ZDon't over-optimize final methods. It is only valid to resolve a final method to a specific implementing function when that function resides in the same parcel as the invocant. A ancestor class in another parcel has the option of adding or removing an implementation, so the descendant class cannot know for sure what function it should resolve to.
There's also the issue of keeping the ABI compatible if the "final" property of a method is removed, and the method implementation is subsequently removed or overridden in a subclass. Such a change is backward compatible, so it should be supported in line with our strong ABI compatibility guarantees.
To make this work, we must only use direct function calls for final methods implemented in a "source" parcel, not in an "included" parcel. Unfortunately, this change mostly defeats the performance effects of making core Clownfish classes like String, Vector, or Hash final. For example, a parcel like Lucy couldn't use a direct function call for things like Vec_Add anymore.
There's always the option to convert a method like Vec_Add into an "inert" function Vec_add (like we did for some Obj methods). But we don't autogenerate bindings for inert functions. It would be nice if it was possible to generate bindings for certain inert functions that take an object of their class ("self") as first argument.
On the other hand, we could simply postulate that a final method must never be made non-final.
Nick
