Scope in controllers

[sdelamo]

@sdelamo

In other guides, we use public modifier for Java controller classes and their methods annotated with @get...
Do we want to change the style to use package private scope ?

@burtbeckwith

I'm fine either way but I prefer to omit public in controllers since it's not needed. Since they're only invoked by the generated code that's in the same package, omitting them in the controllers is a small reminder that controllers aren't injectable or directly invocable from user code.

Until know we had been using public scope in controller methods and at a class level. @burtbeckwith is suggesting to use package-private for those.

I don't have strong feelings. We can do either way. I had default to public because since some of our AOP annotations do not work if the method is private, I did not want users to be tempted to use private.

Whatever, we decide we will do through every guide and be consistent.

A) 👍🏻 Controllers with package-private for classes, constructor and HTTP related methods
B) 👎🏻 Controllers with public for classes, constructor and HTTP related methods
C) 🚀 package-private java, internal kotlin, public groovy

[sdelamo]

@micronaut-projects/core-developers thoughts?

[ilopmar]

I don't have strong opinions about any of the options but if I have to vote I'd say that James suggestions make sense, specially regarding Groovy (I've never used the @PackageScope annotation)

[sdelamo]

I added option C) 🚀 package-private java, internal kotlin, public groovy

[wetted]

My 2¢ worth...
As a consumer of the guides I am unlikely to care about consistency between the different languages. I will use the guide corresponding to the language I use, and probably not care about the others. Given that, I want to see constructs that are idiomatic best-practices to the language I'm using, not something contrived to be consistent across languages.

Apologies if I misunderstood.

[jameskleeh]

@sdelamo Seems the consensus is C

[sdelamo]

I've created an issue.