Is List f() a useful signature

Question

Is List f() a useful signature? Is there any problem with it / using it?

This was an interview question. I know this:

It compiles fine
Use it like List lst = obj.f(), and then I can call on lst only those List methods that do not contain T in their signatures (say, isEmpty(), size(), but not add(T), remove(T)

Does that fully answer the question?

user_2707792 · Answer

This method signature is "useful", in the sense that you can implement non-trivial, non-degenerate methods with it (that is, returning null and throwing errors are not your only options). As the following example shows, such a method can be useful for implementing some algebraic structures like e.g. monoids.

First, observe that List is a type with the following properties:

You know that all elements of this list conform to the type T, so whenever you extract an element from this list, you can use it in position where a T is expected. You can read from this list.
The exact type is unknown, so you can never be certain that an instance of a particular subtype of T can be added to this list. That is, you effectively cannot add new elements to such a list (unless you use nulls / type casts / exploit unsoundness of Java's type system, that is).

In combination, it means that List is kind-of like an append-protected list, with type-level append-protection.

You can actually do meaningful computations with such "append-protected" lists. Here are a few examples:

You can create append-protected lists with a single element:

public static  List pure(T t) {
  List result = new LinkedList();
  result.add(t);
  return result;
}

You can create append-protected lists from ordinary lists:

public static  List toAppendProtected(List original) {
  List result = new LinkedList();
  result.addAll(original);
  return result;
}

You can combine append-protected lists:

public static  List combineAppendProtected(
  List a,
  List b
) {
  List result = new LinkedList();
  result.addAll(a);
  result.addAll(b);
  return result;
}

And, most importantly for this question, you can implement a method that returns an empty append-protected list of given type:
```
public static  List emptyAppendProtected() {
  return new LinkedList();
}
```

Together, combine and empty form an actual algebraic structure (a monoid), and methods like pure ensure that it's non-degenerate (i.e. it has more elements that just an empty list). Indeed, if you had an interface similar to the usual Monoid typeclass:

  public static interface Monoid {
    X empty();
    X combine(X a, X b);
  }

then you could use the above methods to implement it as follows:

  public static  Monoid> appendProtectedListsMonoid() {
    return new Monoid>() {
      public List empty() {
        return ReadOnlyLists.emptyAppendProtected();
      }

      public List combine(
        List a,
        List b
      ) {
        return combineAppendProtected(a, b);
      }
    };
  }

This shows that methods with the signature given in your question can be used to implement some common design patterns / algebraic structures (monoids). Admittedly, the example is somewhat contrived, you probably wouldn't want to use it in practice, because you don't want to astonish the users of your API too much.

Full compilable example:

import java.util.*;

class AppendProtectedLists {

  public static  List emptyAppendProtected() {
    return new LinkedList();
  }

  public static  List combineAppendProtected(
    List a,
    List b
  ) {
    List result = new LinkedList();
    result.addAll(a);
    result.addAll(b);
    return result;
  }

  public static  List toAppendProtected(List original) {
    List result = new LinkedList();
    result.addAll(original);
    return result;
  }

  public static  List pure(T t) {
    List result = new LinkedList();
    result.add(t);
    return result;
  }

  public static interface Monoid {
    X empty();
    X combine(X a, X b);
  }

  public static  Monoid> appendProtectedListsMonoid() {
    return new Monoid>() {
      public List empty() {
        return AppendProtectedLists.emptyAppendProtected();
      }

      public List combine(
        List a,
        List b
      ) {
        return combineAppendProtected(a, b);
      }
    };
  }

  public static void main(String[] args) {
    Monoid> monoid = appendProtectedListsMonoid();
    List e = monoid.empty();
    // e.add("hi"); // refuses to compile, which is good: write protection!
    List a = pure("a");
    List b = pure("b");
    List c = monoid.combine(e, monoid.combine(a, b));
    System.out.println(c); // output: [a, b]
  }

}

user_3788176 · Answer

I interpret "is it a useful signature" to mean "can you think of a use-case for it".

T is determined at the call site, not inside the method, so there are only two things that you can return from the method: null or an empty list.

Given that you can create both of these values in roughly as much code as invoking this method, there isn't really a good reason to use it.

Actually, another value that can be safely returned is a list where all of the elements are null. But this isn't useful either, since you can only invoke methods which add or remove literal null from the return value, because of the ? extends in the type bound. So all you've got is thing which counts the number of nulls it contains. Which isn't useful either.

user_5175102 · Answer

The official Generics tutorial suggests not to use wildcard return types.

These guidelines do not apply to a method's return type. Using a wildcard as a return type should be avoided because it forces programmers using the code to deal with wildcards."

The reasoning given isn't exactly convincing, though.

user_8473028 · Answer

It's not particularly useful, for the reasons given in other answers. However, consider it's "usefulness" in a class like the following (although it's probably a bit of an antipattern):

public class Repository {
    private List

Is <T> List<? extends T> f() a useful signature

4 Answers