The implementation of default methods (original) (raw)

David Holmes david.holmes at oracle.com
Sun Dec 16 20:55:04 PST 2012

On 17/12/2012 2:46 PM, Joshua Bloch wrote:

Complexity meter buried deep in the red.

Any suggestion on how to move it?

David

Josh

On Sun, Dec 16, 2012 at 6:39 PM, David Holmes <david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com>> wrote: On 16/12/2012 1:56 AM, Brian Goetz wrote: For Iterator.remove, I think the real constraint is: the JDK must provide a default implementation (since this is only an issue for compatibility across JDKs). Since the only reasonable default would be to throw something, we might as well specify what is thrown, since this degree of freedom serves noone: the JDK must provide a default that throws UOE.

One example does not a policy make. We have to address the general issue not, I hope, do a case-by-case analysis to see if we think any other default implementation is possible or reasonable. Put another way do we say: "This default implementation does ..." or "The default implementation does ..." ? On a related but separate note, the "is equivalent to" approach has caused not insignificant confusion over the years because no one knows exactly what it means and then we get bug reports because it's only equivalent in the base class, not in any subclasses (eg we call a private method that 'is equivalent to' calling a bunch of public methods but we don't actually call them so overriding in the subclass doesn't have the expected affect). David -----

On 12/15/2012 1:50 AM, David Holmes wrote: On 15/12/2012 2:45 AM, Doug Lea wrote: On 12/14/12 11:30, Brian Goetz wrote: 1. Document "Implementation note: The default implementation currently..." As always, the fewer of these the better. In j.u/j.u.c, these are used mostly for resource limitations (like max threads in FJP) that might someday be lifted. 2. Document "The default implementation behaves as if..." (Or whatever Doug's proposed wording is.) In j.u.c, we always say "is behaviorally equivalent to" but I dropped the "behaviorally" in Map candidate because someone once told me it was overly pedantic :-) 3. Document "The default implementation MUST" Isn't this just the normal spec part, that should precede the default implementation part? I think not. The "normal spec" describes the abstract operation. "The default implementation MUST" specifies the concrete implementation. But it sounds like we do not intend to lock in what these default implementations do, so, for example, my version of j.u.Iterator.remove doesn't have to throw UnsupportedOperationException if I have some magic way of providing a default remove operation - correct? David -Doug

More information about the lambda-libs-spec-experts mailing list