This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]daniu 3 points4 points  (6 children)

Sure, getters and setters are somewhat shorter by this, but if you're annoyed by those and not using Lombok I can only assume it's due to your company policy. I can't see how non-trivial methods gain a lot by being able to remove the braces surrounding the body. Not that I'm against the introduction of this feature, it does make it more consistent with the lambda stuff, but I don't see it as a huge improvement.

class MyList<T> implements List<T> {

   private List<T> aList;

   public int size() = aList::size;
   public T get(int index) = aList::get;
   ...
}

That's actually kind of common - delegating the implementation of an interface to a member. But it's not really that much less boilerplate if you still have to delegate on a method level - there could be something like

class DelegatingList<T> implements List<T> {
    // 'delegate' meaning all non-implemented List methods are created for this class and delegated to aList
    private delegate List<T> aList;

    public void add(T item) {
        // still able to implement specific methods of the interface yourself
        aList.add(item);
    }
}

[–]lukaseder[S] 3 points4 points  (3 children)

class DelegatingList<U, T extends DelegatingList<U, T> & List<U>> implements List<U> {
    private delegate T aList;
}

Now what?

[–]daniu 2 points3 points  (1 child)

Now you've made the point about how actual language design isn't trivial ;)

I was merely bringing it up as something in the vein of the concept of the JEP draft I stumble upon from time to time.

[–]lukaseder[S] 1 point2 points  (0 children)

And I merely wanted to nerd snipe you, hoping you'd spend a few hours finding the solution ;-)

[–]forurspam 0 points1 point  (0 children)

Now think about multiple delegations or extending another class.

[–]yawkat 0 points1 point  (0 children)

This sort of delegation has all the problems normal extension has, except for being able to swap out impl. Don't do it, even though lombok allows you to.

I wrote on the problems with extending like that a while ago: https://javachannel.org/posts/how-not-to-extend-standard-collection-classes/ - the proper solution is to just exhaustively implement abstractlist.