The implementation of default methods

[David Holmes]

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
>
>