Public defender methods and static inner classes in interfaces?

[Collin Fagan]

I keep reading these proposals and I keep reading that public defender
methods have "no state" and yet I can't bring myself to believe it. They may
be intended to have "no state" but that really doesn't mean people aren't
going to try.. and succeed... to make this multiple inheritance or traits or
mix-ins.

Example:

public extension void setExtendedValue(Object parameter)
       default Example1.setExtendedValue;

class Example1 ...

private static IdentityHashMap<Object, Object> extendedValues = new
IdentityHashMap<Object, Object>();

public static void setExtendedValue(Object extendedInstance, Object value){
    extendedValues.put(extendedInstance, value);
}

public static Object getExtendedValue(Object extendedInstance){
    return extendedValues.get(extendedInstance);
}

*POOF* inheritance of state.

I can see entire "frameworks" and/or Spring/Guice/Lombok/Commons
modules/extensions purposefully built to make this easy and manage the
object allocation for you.

*Don't want to have to write all that boiler plate code? Our framework will
allow you to "inject" all the functionality you want! Just use Injectortron!
*

Have you ever needed to modify a final variable in an inner class? Have you
even used the single element array hack? It's all over the web, it's well
known and people use it when that the whole final thing becomes
inconvenient. I have a bad feeling that we have the same situation here. If
you provide this feature someone else is going to "fill the gap" with their
vision of what this functionality *should *have been.

.. and I don't have a solution. I tried, but I'm just not smart enough to
compensate for the erasure of generics. I'm only smart enough to abuse
defender methods.

On Mon, Sep 13, 2010 at 9:03 PM, Jim Mayer <jim at pentastich.org> wrote:

> Hi Dave,
>
> The "defender method" idea seems useful to support extension of existing
> interfaces, but I'm worried that the ability to put algorithms into
> interfaces will blur the distinction between interfaces and classes.  One
> of
> the problems with C++ is that there are so many ways of doing the same
> thing
> that the conventions around the use of a feature become more complicated
> than the feature itself.
>
> Currently interfaces have a well defined purpose: they specify a contract
> without an implementation.  That's a simple concept to get across and the
> language enforces it.  Once we allow algorithms to be implemented in
> interfaces the picture becomes less clear, especially for inexperienced
> developers.
>
> On the other hand, Java interfaces can already contain constants and it's
> hard to argue why, since we're adding lamba like expressions to Java, we
> shouldn't just treat the default methods as constant values.  In fact, I
> think the cleanest proposal is to let interface method definitions have
> bodies... that's the most familiar syntax of all.  I'm just worried about
> unintended consequences... interfaces were introduced, I assume, because of
> the widespread concern about multiple inheritance.  Defender methods raise
> the same issues as multiple inheritance, and the rules for resolving
> ambiguity are (necessarily) non-local in effect.  Adding a new method with
> a
> "defender" seems like an innocent change to an interface, but the non-local
> nature of the conflict resolution algorithms means that it will be easy to
> break existing code or, perhaps worse, produce code that yields unexpected
> results.
>
> Anyway, that's why I would prefer something like the proposal in (
> http://cr.openjdk.java.net/~darcy/DefenderMethods.pdf<http://cr.openjdk.java.net/%7Edarcy/DefenderMethods.pdf>).
>  It's ugly, and that
> seems appropriate here. :-)
>
> -- Jim
>
> On Wed, Sep 8, 2010 at 1:27 PM, David Walend <david at walend.net> wrote:
>
> > On Sep 8, 2010, at 8:59 AM, Jim Mayer wrote:
> >
> >  One problem with the suggestion below (that 'private' be allowed on
> >> classes inside interfaces) is that it won't play nicely with unit
> testing
> >> frameworks such as JUnit.  JUnit conventions rely fairly heavily on
> >> 'package' protection, and a 'private' class inside an interface would be
> >> difficult to test.
> >>
> >> This may, or may not, matter in practice, but I hate to see us do
> anything
> >> that makes unit testing harder.
> >>
> >> My own preference, at this point, would be to keep implementation out of
> >> interfaces as much as possible, provide implementations in a separate
> file,
> >> and hope that the defender method feature isn't abused too much.
> >>
> > <snip>
> >
> > Jim, this is what I'm curious about. What do you see as abuse (vs. wise
> > use)?
> >
> > We can take this off list if no one else is interested. It's sure to
> stray
> > into syntax.
> >
> > Thanks,
> >
> > Dave
> >
> >
> >
>
>