On 27/05/2015 03:44, Marvin Humphrey wrote:
Okeedoke -- I'll rework the pull request to further limit the optimization.
Without JIT compilation or even link-time-optimization, we're not going to see
any kind of big speedup, anyhow. If we could inline the code or at least
resolve to a fixed address, things might be different. But with standard
linking, we're looking at a PLT lookup, which isn't that different from a
vtable lookup. Both involve multiple levels of indirection. Both will cause
a control hazard.
Right, maybe it isn't worth the hassle to implement this optimization at all.
With Go, though, we run into a namespacing problem. Clownfish parcels can
have inert functions with the same name in multiple classes. In Go, they all
end up in the same Go package and will clash.
// Go: ordinary func (not method)
result := example.Add(1, 2)
I see.
On the other hand, we could simply postulate that a final method must never
be made non-final.
I hadn't thought hard about this use case before. Adding `final` to a method
breaks compat because there could be a subclass out there overriding it. I
suppose that removing `final` need only break compat if the compiler performs
optimizations in other parcels. I'm fine with foregoing those optimizations
and making the removal of `final` officially supported.
+1
Nick
