chore: use more fully-qualified names, so that an action can actually be called "Action"#579
Conversation
raboof
left a comment
There was a problem hiding this comment.
I agree we should take this into account better (#437).
Using FQN's in more places would help. I agree with @patriknw that using FQN's everywhere, expecially in the 'unmanaged' templates, is not a great user experience. It looks like this PR only touches the abstract action and the handler, which are both managed, so that seems OK to me.
What I would like to do longer-term is solve this in the typeName and Imports utilities: we could detect clashes there, and add logic to use FQN's only when they're actually needed to avoid clashes. That needs some refactoring though. I'd be OK with merging this now to get you unstuck for the TCK, and the picking up the more 'minimal' approach later.
johanandren
left a comment
There was a problem hiding this comment.
I agree on fq names in the managed classes, but would be very noisy to always have in the user/unmanaged classes by default IMO.
|
Yes, fully agree on keeping unmanaged generated sources clean. I'll have another try at decreasing the verbosity. |
|
I only touch managed bits but I now made it a slight bit less verbose by importing |
The TCK service defined in the framework (https://github.com/lightbend/akkaserverless-framework/blob/0de0598276015466b4a7ae97e9d63052919869dd/protocols/tck/src/main/protobuf/akkaserverless/tck/model/action/action.proto) is called Action, so names clash if we want to generate stubs for it.
Actionmight be generic and short enough that users might also stumble over this. Using more fully-qualified names in code generation avoids this issue.It's a common problem in code generation that you can get naming clashes. We could go all in and use only FQNs for our fixed symbols but that seems a bit of overkill. Changing it for something like
Actionon the other hand might be useful. WDYT?