Skip to content

Conversation

@paracycle
Copy link
Member

Motivation

Implementation

Tests

Copy link
Contributor

@Morriar Morriar left a comment

Choose a reason for hiding this comment

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

What do you think of first doing a refactor to allow compilers to use 2 type builders, one for RBI, one for RBS.

class MyCompiler < Compiler
  def decorate
    # we go from this:
    root.create_path(constant) do |model|
    end

    # to this:
    rbi_builder.create_path(constant) do |model|
    end

   # or this:
    rbs_builder.create_path(constant) do |model|
    end
end

And keep root as a proxy to the rbi_builder so the API is unchanged?

That way we can migrate compilers one by one and not worry about external ones.

@paracycle
Copy link
Member Author

What do you think of first doing a refactor to allow compilers to use 2 type builders, one for RBI, one for RBS.

I don't understand why we need 2 type builders, though. I thought the whole point of the type builder abstraction was to be able to generate RBI syntax or RBS syntax from the same types, and I also got some of that working as well.

@Morriar
Copy link
Contributor

Morriar commented Jan 15, 2026

I don't understand why we need 2 type builders, though. I thought the whole point of the type builder abstraction was to be able to generate RBI syntax or RBS syntax from the same types, and I also got some of that working as well.

Sorry I got confused in the naming, the idea would be to have the current builder that use String for types and the new builder that type RBI::Type. So we can make the migration gradually.

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