Rename #sorbet_type → #__tapioca_type

[amomchilov]

Motivation

Rename the #sorbet_type method called by the JsonApiClient::Resource compiler, to match our naming decision in #2112:

1. Prefixed with __ to discourage the method from being called from regular user code (i.e. only Tapioca should be calling it).
2. Renamed to emphasize Tapioca over Sorbet, to clarify how this ends up being used. Should hopefully be an easier term to search for, with fewer false matches.

Implementation

Print a warning when we find #sorbet_type, while still honouring it. If there's only a definition for #__tapioca_type, we'll use that instead.

After some migration time, we can drop support for #sorbet_type.

[amomchilov]

This assumes that the source_location is available (i.e. this was defined in Ruby, and not in a C extension). Is that safe to assume, or should I guard against it?

Doing so is a bit uglier:

msg = <<~MESSAGE
  WARNING: `#sorbet_type` is deprecated. Please rename your method to `#__tapioca_type`."
MESSAGE

if (source_location = type.method(:sorbet_type).source_location)
  msg.concat("Defined on line #{source_location[0]} of #{source_location[1]}")
end

msg = $stderr.puts

[andyw8]

Could also be nil if there's some metaprogramming involved, so let's play it safe. You could extract out the deprecation stuff so as to not pollute the conditional.

[amomchilov]

Fixed!

[amomchilov]

We don't have assert_nothing_raised, so a comment will suffice.

[amomchilov]

It's surprisingly hard to make a method with no source_location ahha. Native methods from C extensions would have it, but other than that, every way to define a Ruby method ended up having it defined. I tried:

1. define_singleton_method
2. singleton_class.define_method
3. eval
4. class_eval
5. Class.new { ... }

and they all had it defined.

[andyw8]

Interesting.

[amomchilov]

IKR? I could have sworn you needed to explicitly pass in the ___FILE__ and __LINE__ else you got no info at all