Final and FinalArgs

[Lekanich]

We have an idea to add to Lombok two new annotations : FinalArgs and Final. They will annotate methods. Finals will be adding final modifier for all of the parameters and local variables in method, and FinalArgs will convert only arguments. And NonFinal will be contra annotation.

I have some working code for this purpose. https://github.com/Lekanich/lombok

[Andre Bogus]

What are the benefits of using @Final instead of final? Yes, it may shorten your code just a bit if you have many arguments; on the other hand having many arguments is a code smell and should be avoided anyway.

[Happy Hamster]

The benefit is that code is easier to read.

Consider

@FinalArgs @NonNullArgs

public Connection attachToProcess(InferredProcess inferredProcess, ConnectionConfig connectionConfig, FutureCallback callback) throws Exception {}

 - vs - 

public Connection attachToProcess(@NonNull final InferredProcess inferredProcess, @NonNull final ConnectionConfig connectionConfig, @NonNull final FutureCallback callback) throws Exception {}

I don't think that 3 arguments is a code smell.

[Reinier Zwitserloot]

No, but just blanket declaration that they must all be @NonNull is weird. Why not introduce @Strings, which declares that all arguments are strings? Where does it end?

I can see @FinalArgs in the sense that some misguided souls believe that all params should be final, but I think that's a bad habit, so I'm loathe to support this bad habit by adding a lombok annotation that serves no purpose other than to prolong the bad habit. Especially now that java 8 is around, where 'final' has no actual benefit anymore (merely being effectively final is enough for use in lambdas), the 'all params final' code style should hopefully go the way of the dodo.

 --Reinier Zwitserloot

--
You received this message because you are subscribed to the Google Groups "Project Lombok" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-lombo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Martin Grajcar]

On Tue, Dec 2, 2014 at 2:34 PM, Reinier Zwitserloot <rei...@zwitserloot.com> wrote:

No, but just blanket declaration that they must all be @NonNull is weird. Why not introduce @Strings, which declares that all arguments are strings? Where does it end?

There's @ParametersAreNonnullByDefault in JSR 305 and IMHO that's the right point to end at. In some codebases (e.g., Guava), most of the time no nulls are allowed. To make an exception, @Nullable gets used. No other property of the arguments holds nearly as often.

As Lombok implements @NonNull and no other such checks, there's already a precedent.

I can see @FinalArgs in the sense that some misguided souls believe that all params should be final, but I think that's a bad habit, so I'm loathe to support this bad habit by adding a lombok annotation that serves no purpose other than to prolong the bad habit.

I guess, I'd use @FinalArgs, too, although I definitely don't believe that arguments must be final. They just often happen to be. I only love to mark everything being final as such, since I consider it being easier to read.  But placing final in the method signature would make it too long, so I never do it (while @FinalArgs could be fine). There are cases when modifying the arguments (e.g., some normalization) is surely a good thing as it prevents bugs like mistakenly using the original value.

Anyway, something like @ParametersAreNonnullByDefault would be IMHO way more useful.

[Happy Hamster]

@ Reinier Zwitserloot 

I don't have time to argue about misguidance of souls here -- a lot has been written on immutability of objects previously and best practices in regards to that have been covered by numerous experts. Modern JVM based languages such as Scala have immutable args by default, unless explicitly declared mutable. 

Your statement that "final" has been effectively deprecated since Java 8 is wrong for various reasons. Your @Strings argument is comparing oranges to apples.

That said, I could not care less if you don't accept the proposed features into lombok codebase it's the reasons why that sadden me.

--
You received this message because you are subscribed to a topic in the Google Groups "Project Lombok" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/project-lombok/nGNbyDn0Qps/unsubscribe.
To unsubscribe from this group and all its topics, send an email to project-lombo...@googlegroups.com.

[Happy Hamster]

There's @ParametersAreNonnullByDefault in JSR 305 and IMHO that's the right point to end at. In some codebases (e.g., Guava), most of the time no nulls are allowed. To make an exception, @Nullable gets used. No other property of the arguments holds nearly as often.

Honestly I've never came across JSR 305, thanks for pointing that out.

I'm a team lead of the topic starter here and we actually have @NonFinal in our Lombok fork to explicitly declare a variable mutable within method body or argument, so that is similar to @Nullable.

We too as a coding standard "final everything" that is not meant to me mutable by design (and actually final every class that has not been designed specifically to be extendable) and @NonNull everything that is not indented to accept null as a meaningful value. So for us @Final, @NonFinal, @FinalArgs, @NunNullArgs are a time saver and if these are not accepted into main lombok repo we will just fork it or  continue using our codebase internally. Just though it'd might be useful to the community.

PS: We actually have few other Lombok patches and we also maintain a fork of an Intellij IDEA plugin to support our patches.

[John]

I think that everything should be final by default except for a few things like accumulators. I would like something functionally equivalent to @FinalArgs to be released soon. 

[Reinier Zwitserloot]

The project owners do not share your thoughts on this issue, I'm afraid. Not gonna happen.