fix(go): fix generation of readonly and static properties

[SoManyHs]

Previously, we were generating setters for readonly properties, as well as including static properties as part of a class interface and implementation. This fixes the property generation to omit the setter declarations/implementations for readonly properties. It also generates static properties as the package level.

Fixes #2093

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[SoManyHs]

NOTE: It maybe worth considering refactoring this so that the static properties are wrapped in a StaticProperty class and then have a list StaticProperty[] as a member on the GoClass as we do with staticMethods; however, I wanted to wait until the StaticGet jsii call is implemented before doing so. I tried a few ways of having a StaticProperty class extend from existing classes, but none of the abstractions seemed to quite fit so simply made a emitStaticProperty private method on the class instead of following the usual SomeConstruct.emit() pattern. @MrArnoldPalmer

[MrArnoldPalmer]

NOTE: It maybe worth considering refactoring this so that the static properties are wrapped in a StaticProperty class and then have a list StaticProperty[] as a member on the GoClass as we do with staticMethods; however, I wanted to wait until the StaticGet jsii call is implemented before doing so. I tried a few ways of having a StaticProperty class extend from existing classes, but none of the abstractions seemed to quite fit so simply made a emitStaticProperty private method on the class instead of following the usual SomeConstruct.emit() pattern. @MrArnoldPalmer

I think this is the right way to go. That would also remove the need for these checks

   for (const prop of this.properties) {
      if (prop.static) {
        // emit static get
...

    for (const property of this.properties) {
      if (!property.static) {
        // emit non-static get
...

There isn't a lot of shared behavior between static and non-static property getters so a common ancestor wouldn't have much. Basically the only common thing it needs is the stuff declared on the GoTypeMember + the immutable property.

This could warrant an abstract wrapper class, or maybe just another interface like

interface GoPropertyMember extends GoTypeMember {
  immutable: boolean
}

Since they would take the same constructor args maybe an abstract class is best.

[RomainMuller]

Added pr/do-not-merge if you wanna take the refactor route in this PR (I'm cool if you prefer to do it separately, too - in which case just drop the label or have @MrArnoldPalmer drop it).

Pull request has been modified.

Pull request has been modified.

[SoManyHs]

@Mergifyio update

[mergify]

Command update: success

Branch already up to date

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildProject6AEA49D1-Blkkw9bQFn8A
• Commit ID: 9560eb1
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[SoManyHs]

@Mergifyio update

[mergify]

Command update: success

Branch already up to date

[mergify]

Thank you for contributing! ❤️ I will now look into making sure the PR is up-to-date, then proceed to try and merge it!

[RomainMuller]

@Mergifyio refresh

[mergify]

Command refresh: success

Pull request refreshed

[mergify]

Merging (with squash)...