Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Attribute#ivar_name API is unclear #2109

Open
amomchilov opened this issue Dec 2, 2024 · 0 comments
Open

Attribute#ivar_name API is unclear #2109

amomchilov opened this issue Dec 2, 2024 · 0 comments

Comments

@amomchilov
Copy link
Contributor

amomchilov commented Dec 2, 2024

The #ivar_name attribute of each RBS::Members::Attribute* class can return one of 3 things:

# ivar_name will return `nil`, which indicates the default (@a) is inferred
attr_reader a: Integer

# ivar_name will return `:something_else`
attr_reader b(@something_else): String

# ivar_name will return `false`
attr_reader c(): bool

This has a few downsides:

  1. The distinction between nil and false is subtle and non-obvious

  2. Most callers (e.g. a type checker, LSP, etc.) probably care about the instance variable name regardless of whether it was inferred or explicit, and will have to compute it themselves when they get nil.

  3. The RBS type of this field is complex:

    attr_reader ivar_name: Symbol | false | nil

    • This will also makes the C API less clear, since the type has to be some general node type (e.g. rbs_node_t *), rather than specifically a symbol type (rbs_symbol_t * or NULL).

I propose we deprecate this field, and come up with an easier-to-consume alternative.

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

No branches or pull requests

1 participant