Skip to content

generate getters and setters consistently with qnames#451

Draft
mikesamuel wants to merge 1 commit into
mainfrom
getters-and-setters-for-all
Draft

generate getters and setters consistently with qnames#451
mikesamuel wants to merge 1 commit into
mainfrom
getters-and-setters-for-all

Conversation

@mikesamuel

Copy link
Copy Markdown
Contributor

Trying to see if generating getters and setters (including pureVirtual ones for interfaces) might simplify some things.

Still need to maybe drop pureVirtual bodies to make declaring abstract easier and make it easier for backends that only want getters and setters when they are semantically different from a direct read of a backed property to skip such setters and getters.

Signed-off-by: Mike Samuel <mikesamuel@gmail.com>
.snapshot(configKey, AstSnapshotKey, root)
}

Debug.Frontend.DefineStage.FillInMissingQNames(configKey)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just make sure there're qnames on anything that was added since.

| I__0<T__0> extends AnyValue;
| @property(\x) @visibility(\public) @QName("test-code.type I.x") @stay @fromType(I__0<T__0>) let x__3: T__0;
| @property(\y) @visibility(\public) @QName("test-code.type I.y") @stay @fromType(I__0<T__0>) let y__1;
| @property(\y) @visibility(\public) @stay @fromType(I__0<T__0>) @QName("test-code.type I.y") let y__1: Int32;

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now when there's a setter, we infer the type of the abstract property properly.

@tjpalmer

tjpalmer commented Jul 1, 2026

Copy link
Copy Markdown
Contributor

Overall looking good. And I can't tell from a glance, but for interfaces, I think it would be good to generate the exact same internal representation for either of these:

interface Hi {
  message: String;
  var name: String;
}
interface Hi {
  get message(): String;
  get name(): String;
  set name(name: String);
}

Maybe we should prefer one to the other, but from an interface perspective, I think these should mean the same thing.

These would be different for classes, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants