The implementation of default methods

[Joshua Bloch]

Complexity meter buried deep in the red.

    Josh

On Sun, Dec 16, 2012 at 6:39 PM, David Holmes <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
>>>>
>>>>