Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for explicit receiver parameters #789

Merged
merged 1 commit into from
Jun 5, 2020

Conversation

jasonobrien
Copy link
Contributor

Annotated "this" arguments for instance methods and non-static nested
class constructors were added in Java 8. This special cases "this" and
"OuterClass.this" so that they are allowed as parameter names.

Closes #787

Annotated "this" arguments for instance methods and non-static nested
class constructors were added in Java 8. This special cases "this" and
"OuterClass.this" so that they are allowed as parameter names.
}

@Test public void receiverParameterNestedClass() {
ParameterSpec.Builder builder = ParameterSpec.builder(int.class, "Foo.this");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh crap this is scary. Does this work with Foo.Bar.this? Or com.example.Foo.this? If so, that means it probably needs to participate in the automatic import system to ensure you're referring to what you actually mean.

Copy link
Contributor Author

@jasonobrien jasonobrien Jun 4, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Luckily Foo.this can only be used from the constructor of a direct nested type of Foo, so no import required.

In fact, the grammar only allows a single unqualified identifier, so even if you managed to make it ambiguous (another inner nested type with the outer types name?), there's nothing JavaPoet could do to make it compile I think.

ReceiverParameter:
{Annotation} UnannType [Identifier .] this

That said, this is the simplest solution but probably not the most elegant - if the grammar was more complicated, I might suggest MethodSpec.Builder#receives(TypeName) with the identifier derived automatically during emission instead.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not worried about it then. Thanks! Frankly I don't expect many to ever need this feature as-is but it's so easy to support we might as well add it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree - relevant receiver annotations seem pretty rare (I only know the one), and needing one in a generated class even more so.

If support for Java 8 annotations was otherwise lacking I'd probably have just hacked around it, but it seems very thorough. Thanks for looking!

@JakeWharton JakeWharton merged commit e77793b into square:master Jun 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Explicit receiver parameters
2 participants