Skip to content

Conversation

@stevegeek
Copy link

@stevegeek stevegeek commented Oct 25, 2025

Adds support for say attr_accessor :thing => String via AST processing

An open question is on syntax. Currently is supports both hash and keyword hash syntax for the name/type pairs... but this might be confusing for diffenerent cases, eg attr_reader where probably => syntax is more consistent with fun
eg

attr_reader :name => String # This makes sense to me
# or
attr_reader name: String  # ... strange if compared to `fun` signatures

attr_accessor :name => String # ok as reader returns a string ?
# or
attr_accessor name: String # ok as `name=` also takes a string  ?

attr_writer :name => String  # ok as writer also returns written value ?
# or
attr_writer name: String # maybe better as writer method takes argument of String?

Also set this up to check types on write of attr_writer and attr_accessor and on read of attr_reader ... not sure if thats ok and if attr_accessor should check on read instead? (as often accessors are 'set' by setting ivars directly?)


If we don't care about the specifics of the syntax (keyword vs hash rockets), on the implementation I guess the better thing to do here tho is to just override the attr_ methods rather than using prism? (though just would need to be careful on visibility of wrapper methods if using inline visibility modifiers)

Also thinking out loud... since keyword syntax would look like kwargs while => would appear as a hash argument I guess you can even differentiate the syntax via just interrogating the arguments

But still need to consider how to handle visibility... how to define wrapper methods of attr_ that preserves visibility , eg

private

attr_reader :thing => String

if I override attr_reader (to parse the type signature), then call to the original attr_reader implementation the methods generated by it are now public.

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.

1 participant