`.h` files are not something to emulate! External interfaces should be generated by tools where needed.
`.h` files are not something to emulate! External interfaces should be generated by tools where needed.
Here's a full example, complete with a typo, based on the example in the blog post: https://bit.ly/3hMEMSp
Here's a truncated excerpt to get the basic idea across:
    # typed: true
    class Merchant
      extend T::Sig
      sig {returns(String)}
      attr_reader :name
      sig {returns(T::Array[Employee])}
      attr_reader :employees
      sig {params(token: String, name: String).void}
      def initialize(token, name)
        @token = token
        @name = name
      end
    end
    class Merchant
      attr_reader token: String
      attr_reader name: String
      attr_reader employees: Array[Employee]
      def initialize(token: String, name: String) -> void
         # actual method body
      end
      def each_employee: () { (Employee) -> void } -> void
                   | () -> Enumerator[Employee, void]
          # actual implementation body
      end
    end
The Ruby syntax is too complicated to allow for changes like this to be backwards-compatible.
For example, `attr_reader token: String` is valid ruby today – that's the same as `attr_reader(:token => String)` which somebody might be doing in the wild, since you can override `def self.attr_reader`.
Similarly, `def initialize(token: String` clashes with the definition of keyword arguments.
I am not able to spin that into "And besides it's better to force it to be in two files anyway!", I don't think it is, but I guess it's not so easy to do different.
Mind you, if we could write tests in .rbs then I guess .rbs could form the basis of a new ruby syntax without breaking compatibility with old code in .rb files.