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.

Sign up for GitHub

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

Jump to bottom

support for lambda functions #6

Closed

HliasMpGH wants to merge 10 commits into Randgalt:master from HliasMpGH:master

Contributor

HliasMpGH commented Apr 18, 2024

*testing
*documentation

HliasMpGH added 3 commits

April 14, 2024 13:18


          add lambda creation feature

06c4f80

*add lambda with body feature
*add overloads of lambda creation


          add lambda usability for CodeBlocks

130b30d


          add lambda creation feature

b905d13

*add testing
*add javadoc documentation

Contributor Author

HliasMpGH commented Apr 18, 2024 •

edited

Loading

This PR issues changes such as:

CodeBlock & MethodSpec:
-addLambda() overloads used for constructing different types of lambda functions.
-testing for different cases.

A plugin addition to the build, used for producing javadoc from source.
Some reformatting of variable declaration and javadoc.
A bug fix on TypeSpec where an overload of addPermits(), created an infinite recursion.

Randgalt reviewed

View reviewed changes

src/main/java/com/squareup/javapoet/TypeSpec.java

                   public Builder addPermits(Iterable<? extends TypeName> permits) {
                     checkArgument(permits != null, "permits == null");
                     for (TypeName permit : permits) {
-                      addPermits(permits);
+                      addPermits(permit);

Owner

Randgalt Apr 18, 2024

nit: I'd put this in a separate commit as it's not related to this commit

Contributor Author

HliasMpGH Apr 18, 2024

Must have missed it while squashing my commits, sorry for the inconvenience. Thanks!

Owner

Randgalt Apr 24, 2024

Have you pushed latest? I'm still seeing this in the 1 commit.

Owner

Randgalt commented Apr 18, 2024 •

edited

Loading

Thanks - I'll review as I have time. I'm not very familiar with the JavaPoet code base but I'll do my best. Maybe we can get some others to review from the community.

Randgalt reviewed

View reviewed changes

pom.xml

@@ @@ -135,6 +135,16 @@ @@
                   <build>
                       <pluginManagement>
                           <plugins>
+                              <plugin>

Owner

Randgalt Apr 24, 2024

Why is this needed? If just personal preference please put in a separate commit with its own comment.

Contributor Author

HliasMpGH Apr 27, 2024

I will make sure that every change apart from the lambdas will be in a separate commit

Randgalt reviewed

View reviewed changes

src/main/java/com/squareup/javapoet/CodeBlock.java Outdated

+                   * @param args the values that should be placed in the holders
+                   * of the format.
+                   */
+                  public Builder addLambda(List<ParameterSpec> parameters, String expressionFromat, Object... args) {

Owner

Randgalt Apr 24, 2024

Spelling: expressionFromat should be expressionFormat (multiple places)

Randgalt reviewed

View reviewed changes

src/main/java/com/squareup/javapoet/CodeBlock.java Outdated

+                    // the inputs of the lambda (left side)
+                    String inputSide = String.join(
+                      ", ", parameters.stream()
+                      .map(p -> p.toString())

Owner

Randgalt Apr 24, 2024

Can be: .map(ParameterSpec::toString)

Owner

Randgalt Apr 24, 2024

Whole thing can be:

Suggested change

      
                    .map(p -> p.toString())
          
                  String inputSide = parameters.stream()
          
                  .map(ParameterSpec::toString)
          
                  .collect(Collectors.joining(", "));

Contributor Author

HliasMpGH Apr 27, 2024

Ah, i see. Thank you for pointing it out!

Randgalt reviewed

View reviewed changes

src/main/java/com/squareup/javapoet/CodeBlock.java Outdated

+                    // check that the input types are valid
+                    for (ParameterSpec parameter : parameters) {
+                      checkArgument(!parameter.type.equals(TypeName.VOID),
+                        "lambda input parameters cannot be of void type!");

Owner

Randgalt Apr 24, 2024 •

edited

Loading

nit: the rest of JavaPoet messages do not use !

Randgalt reviewed

View reviewed changes

src/main/java/com/squareup/javapoet/CodeBlock.java Outdated

+                   * @param parameters the input parameters of the function.
+                   * @param body the body of the function.
+                   */
+                  public Builder addLambda(List<ParameterSpec> parameters, CodeBlock body) {

Owner

Randgalt Apr 24, 2024

To be consistent with the rest of JavaPoet these should be Iterable<ParameterSpec>. You can convert to a stream via:

Stream<ParameterSpec> parameterSpecStream = StreamSupport.stream(parameters.spliterator(), false);

Randgalt reviewed

View reviewed changes

src/main/java/com/squareup/javapoet/CodeBlock.java Outdated

+                   * @param args the values that should be placed in the holders
+                   * of the format.
+                   */
+                  public Builder addLambda(List<ParameterSpec> parameters, String expressionFromat, Object... args) {

Owner

Randgalt Apr 24, 2024

Same as above, make Iterable to match rest of the library

Owner

Randgalt commented Apr 24, 2024

I have a general comment about this. I think we should consider a more complete solution. Right now, this modifies CodeBlock and generates a lambda like this:

(double y) -> {return x + y;}

This is good but not ideal. If I were to write the above lambda, I'd write:

y -> x + y;

Instead of modifying CodeBlock with addLambda we probably need a LambdaSpec similar to MethodSpec that can analyze the parameters, return type, etc. and build a lambda more like what developers expect.

wdyt?

Contributor Author

HliasMpGH commented Apr 27, 2024 •

edited

Loading

I have a general comment about this. I think we should consider a more complete solution. Right now, this modifies CodeBlock and generates a lambda like this:
(double y) -> {return x + y;}
This is good but not ideal. If I were to write the above lambda, I'd write:
y -> x + y;
Instead of modifying CodeBlock with addLambda we probably need a LambdaSpec similar to MethodSpec that can analyze the parameters, return type, etc. and build a lambda more like what developers expect.

wdyt?

You are right. My initial thought was to follow the LambdaSpec class idea, and that would be required if we want to allow code like

x -> x + 3;

The reason i avoided the idea was because it appeared to me that maybe it wouldnt fit with the rest of the Spec's of the project and was an an overkill to have a separate class for that, thats why i went through with the current implementation. That doesnt mean though that LambdaSpec cant be a thing, and since you propose it as well, i can make the changes needed to support it. My idea of the final code will be something like this:

ParameterSpec consumerLambda = ParameterSpec.builder(
	ParameterizedTypeName.get(
				ClassName.get(Consumer.class),
				TypeName.get(Integer.class)
			),"consumer"
		).build();

ParameterSpec p = ParameterSpec.builder(TypeName.INT, "x").build();

CodeBlock body = CodeBlock.builder().add("x + 5").build();

LambdaSpec lambda = LambdaSpec.builder(consumerLambda).addInput(p).addBody(body).build();

that will output something like this:

Consumer<Integer> consumer = x -> x + 5;

or

LambdaSpec lambda = LambdaSpec.builder().addInput(p).addBody(body).showTypes().build();

to produce:

(int x) -> x + 5;

for more general use (for example if we need to pass it as input to a method).

We would then have methods such as addLambda(LambdaSpec) in CodeBlock, that would be used for the final construction.

Does that make sense?


          merge annotation support for record fields

ffe94bc

Owner

Randgalt commented Apr 30, 2024

@HliasMpGH I don't think a LambdaSpec builder is necessary if we can get the output to be ideal with only a CodeBlock. wdyt?

Contributor Author

HliasMpGH commented Apr 30, 2024

@HliasMpGH I don't think a LambdaSpec builder is necessary if we can get the output to be ideal with only a CodeBlock. wdyt?

So you are thinking of a LambdaSpec class that does not follow the builder pattern at all? If its convenient, can you provide me with an example of the idea you propose? Thanks

Owner

Randgalt commented Apr 30, 2024

Sorry, no, I meant keep what you have but make it be able to build an ideal statement. I'm not sure if it's possible.

Contributor Author

HliasMpGH commented Apr 30, 2024

Sorry, no, I meant keep what you have but make it be able to build an ideal statement. I'm not sure if it's possible.

Ohh i see. Okay, i will do my best to try and add that ability.

HliasMpGH added 6 commits

April 30, 2024 20:37


          sync with upstream

15e0199


          nit: fix infinite recursion bug on method call

beb18ef


          add javadoc generation plugin on build

49534e2


          fix typos on parameter names

46d5211


          remove ! from exception message

71afbec


          improve lambda feature

4e2357e

Contributor Author

HliasMpGH commented May 9, 2024 •

edited

Loading

Closing to reduce the pollution made from this PR. The implemented result can be seen (more clearly) in #8

HliasMpGH closed this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet