AutoValue for Java 8 Interfaces about auto HOT 11 CLOSED

A possible workaround:

public interface Human {
  static Human create(String name) {
    return new AutoValue_HumanImpl(name);
  }

  String name();
}

@AutoValue
abstract class HumanImpl implements Human {}

It's an extra bit of boilerplate, but it could pay off if there are enough properties.

from auto.

Still, I'd like to have this choice :) In reference to the restrictions you mention:

• public accessors are quite common. In case they're not acceptable I can always switch to an abstract class
• in most cases the value objects don't need to cache/carry additional data. In case it's needed, I can always switch to an abstract class :)
• in most cases instead of having the empty package-private constructor in every auto-value class (which needs a comment at least), I'd rather write a single test that would check by reflection that the @AutoValue-annotated interfaces only have one implementation each. Sure, this does not prevent implementations outside the project. If enforcing immutability outside the project is needed as well, I can always switch to an abstract class ;)

from auto.

I think there is value in being able to omit public abstract, considering the main purpose of AutoValue is to reduce boilerplate. Allowing interfaces would also be more in the spirit of "not restricting your freedom" if it doesn't pose a concrete problem.

from auto.

Advantage?

from auto.

I don't know any advantages other than leveraging a new feature of the language. Perhaps mocking?

from auto.

The notion of mocking an AutoValue type is ... I can't use any word for it
short of "obscene."

On Fri, May 2, 2014 at 2:15 PM, Jake Wharton [email protected]:

I don't know any advantages other than leveraging a new feature of the
language. Perhaps mocking?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/86#issuecomment-42079816
.

Kevin Bourrillion | Java Librarian | Google, Inc. | [email protected]

from auto.

Haha. I'm really just geeking out on Java 8 features and wanted to leverage them for value-y types. The early Java 9 proposal has them much more akin to classes so perhaps keeping them as such here is wise.

from auto.

Actually, this would be more terse and readable than the abstract class with all abstract methods. WDYT? I just spotted AutoValue and it (outlining the Value as an interface instead of an abstract class) is the first thing I was missing in the docs ;)

from auto.

I see that it spares you from typing "abstract" on each accessor. And in the event that you want them to be public it spares you from typing that too. Is there any other terseness/readability gain I'm missing?

The choice to use an interface will restrict your freedom in a few ways:

• your accessors will have to be public
• you won't be able to have any other fields (like caching a derived value)
• you lose the option of preventing subtypes (by adding a package-visible constructor)

from auto.

It's already quite understood that these three restrictions are not massive
and that one can always switch back.

But I claim the benefit of skipping "public abstract" is also not massive.

If we did add this support, we would add a "best practice" to the user
guide suggesting not to even use the feature we're adding. Which should
always give us pause about adding it.

On Wed, May 20, 2015 at 3:32 PM, ArturGajowy [email protected]
wrote:

Still, I'd like to have this choice :) In reference to the restrictions
you mention:

• public accessors are quite common. In case they're not acceptable I
  can always switch to an abstract class
• in most cases the value objects don't need to cache/carry additional
  data. In case it's needed, I can always switch to an abstract class :)
• in most cases instead of having the empty package-private
  constructor (which needs a comment at least), I'd rather write a single
  test that would check by reflection that the @AutoValue-annotated
  interfaces only have one implementation each. Sure, this does not prevent
  implementations outside the project. If enforcing immutability outside the
  project is needed as well, I can always switch to an abstract class ;)

—
Reply to this email directly or view it on GitHub
#86 (comment).

Kevin Bourrillion | Java Librarian | Google, Inc. | [email protected]

from auto.

I could imagine that this could be investigated again when/if value types arrive and if they mandate not being subclasses of abstract classes. Then there would be a much stronger value proposition for having that feature besides omitting public (abstract).

from auto.