You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the course of exercising abstract hierarchies I frequently find myself wanting to specify a type in terms of the methods it must implement without wanting to impose the additional requirement of implementing a specific interface. One can do this but the penalty for doing so is severe and, it appears to me, unnecessary.
In Concrete2 we override the method with a syntactically identical version of the inherited method. The impact is profound.
In Concrete1: a call to foobar forwards the target object and argument to Trait.foobar, where the integer is boxed and placed in an array, the method handle is looked up, the reflective call is issued, the result is unboxed, and it is returned to the calling class.
In Concrete2: a call to foobar results in a direct unboxed call to foo.bar.
But surely if manually overriding each method with an exact copy achieves this, the compiler could assume the responsibility.
The text was updated successfully, but these errors were encountered:
In particular martin says: "In principle this is possible, and it could indeed be very useful to do this. In practice it's harder than it looks (aren't things always?)
What about fields that are private in the base trait? How to estimate when such copying is beneficial and not just a waste of code? How to do this in the presence of separate compilation?"
In the course of exercising abstract hierarchies I frequently find myself wanting to specify a type in terms of the methods it must implement without wanting to impose the additional requirement of implementing a specific interface. One can do this but the penalty for doing so is severe and, it appears to me, unnecessary.
Consider:
In Concrete2 we override the method with a syntactically identical version of the inherited method. The impact is profound.
In Concrete1: a call to foobar forwards the target object and argument to Trait.foobar, where the integer is boxed and placed in an array, the method handle is looked up, the reflective call is issued, the result is unboxed, and it is returned to the calling class.
In Concrete2: a call to foobar results in a direct unboxed call to foo.bar.
But surely if manually overriding each method with an exact copy achieves this, the compiler could assume the responsibility.
The text was updated successfully, but these errors were encountered: