Enhance @with by supporting multiple arguments

[mreuvers]

Hey Joe,

As said, this is a useful enhancement. I intend to add this (creating this issue to track). It will look like this:

@with (String s=list.get(0), List<Long> list=x.getIt()) {
 ...
}

And an equivalent java 8 version. The change will be backwards compatible, so the single argument switch will remains working as is.

There is however one thing I am not sure about, the null-safe with statement.
If multiple arguments are present, and the with statement is tagged with '?'.
What shall we do:

• Execute the block inside, if all the arguments are non-null
• Forbid the null-safe with if there's more than 1 argument
• ...

Example:

@with? (String s=list.get(0), List<Long> list=x.getIt()) {
 ..
}
else {

}

What are your thoughts?

[jjlauer]

I like the syntax. Good question on what to do for the null-safe with. Perhaps go the safe route -- forbid multiple arguments with the null-safe version. If in real world usage its annoying then we could always allow the other option since it'd be backwards compatible.

…

On Fri, Dec 2, 2016 at 9:41 AM, Martijn Reuvers ***@***.***> wrote: Hey Joe, As said, this is a useful enhancement. I intend to add this (creating this issue to track). It will look like this: @with (String s=list.get(0), List<Long> list=x.getIt()) { ... } And an equivalent java 8 version. The change will be backwards compatible, so the single argument switch will remains working as is. There is however one thing I am not sure about, the null-safe with statement. If multiple arguments are present, and the with statement is tagged with '?'. What shall we do: - Execute the block inside, if *all* the arguments are non-null - Forbid the null-safe with if there's more than 1 argument - ... Example: @with? (String s=list.get(0), List<Long> list=x.getIt()) { .. } else { } What are your thoughts? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#43>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjwAq1H1DQdKQtrDmPhWc8sOaoY232cks5rEC4ZgaJpZM4LCnkV> .

[mreuvers]

Ok, that felt like the better option to me as well. Going to pick this one up then. :)

[mreuvers]

Hey @jjlauer,

While working on some tests for the with block, I encountered the following:

@with(String s = s.get(0)) {
  @s
}
else {
  // it will never get here, but the else is allowed here
}

The above is currently allowed already, though the else will never be executed since this is not a null-safe block (it is a bit like dead code).
This may be a bug, and it may be nice to actually have it fail, so users do get an error about it.

I can fix this alongside this enhancement if you want, to allow the else only for a null-safe with block. I intend to forbid it already for the multiple arguments one anyway.

What has your preference?

[jjlauer]

A compiler error would be great.

…

On Dec 3, 2016 10:18 AM, "Martijn Reuvers" ***@***.***> wrote: Hey @jjlauer <https://github.com/jjlauer>, While working on some tests for the with block, I encountered the following: @with(String s = s.get(0)) { @s } else { // it will never get here, but the else is allowed here } The above is currently allowed already, though the else will never be executed since this is not a null-safe block (it is a bit like dead code). This may be a bug, and it may be nice to actually have it fail, so users do get an error about it. I can fix this alongside this enhancement if you want, to allow the else only for a null-safe with block. I intend to forbid it already for the multiple arguments one anyway. What has your preference? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#43 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjwAiAzPwTMzkIZI7BfWg4xcndvmO0-ks5rEYhEgaJpZM4LCnkV> .

[mreuvers]

Hey @jjlauer,

All right.

How do we want to escape the comma, as it can easily be used in the expressions e.g.

@with (List<String> subs = strings.sublist(1\,2), List<String> anotherSub=strings.subList(0\,1).subList(0\,1), String t = "hello\, world") {
}

In the above example I escaped the relevant ones with a single back slash, I guess that would be my preference. What do you think?

[jjlauer]

Escaping won't work. Only solution is to get advanced with antlr or use a different delimiter like a semi colon. See how the syntax looks with a semi colon.

…

On Dec 3, 2016 2:36 PM, "Martijn Reuvers" ***@***.***> wrote: Hey @jjlauer <https://github.com/jjlauer>, All right. How do we want to escape the comma, as it can easily be used in the expressions e.g. @with (List<String> subs = strings.sublist(1\,2), List<String> anotherSub=strings.subList(0\,1).subList(0\,1), String t = "hello\, world") { } In the above example I escaped the relevant ones with a single back slash, I guess that would be my preference. What do you think? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#43 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjwAkFVTRnMrvwbVbYbD9_GcepmQqNCks5rEcTRgaJpZM4LCnkV> .

[mreuvers]

Semicolon would not really work either, since it can be used inside a String (see above).

I'll think about it for now on how to deal with it. If I get the comma working I prefer that over something else. If not then we can do something else.

[mreuvers]

Hey @jjlauer

I had other things to do past month, but at last I had the time to deal with this. I just created a pull request to resolve this enhancement.

See the request for all the details, in short it uses the normal comma and no escapes are necessary.

Could you merge it in and release the version later on?

Thanks!

[mreuvers]

Thanks for applying the pull request and releasing @jjlauer!

I will close this issue then. :)