Skip to content

New asFixnum, asBoolean, asString in Convert#8317

Merged
enebo merged 1 commit intojruby:9.5-devfrom
enebo:api_changes2
Jul 22, 2024
Merged

New asFixnum, asBoolean, asString in Convert#8317
enebo merged 1 commit intojruby:9.5-devfrom
enebo:api_changes2

Conversation

@enebo
Copy link
Member

@enebo enebo commented Jul 16, 2024

Note: asString overlaps with a method on IRubyObject so this may be changing its name.

These are the first methods to replace Ruby.newFixnum sorts of methods. Decoupling this is good for reasons:

  1. Ruby is some mega method holder and it has long lost favor as an object vs ThreadContext.
  2. Passing ThreadContext to all JRuby methods (long term goal) means we increasingly do not need Ruby in Ruby objects at all (very long term goal).
  3. Using static methods decouples our implementation from our API

This round did not completely eliminate all uses of the three methods but it converted hundreds of them. The biggest disruption in this PR is that a lot of @JRubyMethods which did not have ThreadContext now has them. This meant keeping the old method around but marking it deprecated. The fact we need to do this is a prime reason why the API initiave will pay off since there will come a time when we do not need to worry about people consuming our methods. The other side of this is our API will also be exposed properly once we fully modularize (which will mean we long convert people to these methods before we get to point where we cut off access to our other public methods -- which is out impl).

Note: asString overlaps with a method on IRubyObject so this may be changing
its name.

These are the first methods to replace Ruby.newFixnum sorts of methods.
Decoupling this is good for reasons:

  1. Ruby is some mega method holder and it has long lost favor as an
     object vs ThreadContext.
  2. Passing ThreadContext to all JRuby methods (long term goal) means
     we increasingly do not need Ruby in Ruby objects at all (very long
     term goal).
  3. Using static methods decouples our implementation from our API

This round did not completely eliminate all uses of the three methods but
it converted hundreds of them.  The biggest disruption in this PR is that
a lot of @JRubyMethods which did not have ThreadContext now has them.  This
meant keeping the old method around but marking it deprecated.  The fact we
need to do this is a prime reason why the API initiave will pay off since
there will come a time when we do not need to worry about people consuming
our methods.  The other side of this is our API will also be exposed properly
once we fully modularize (which will mean we long convert people to these
methods before we get to point where we cut off access to our other public
methods -- which is out impl).
@enebo enebo added this to the JRuby 10.0.0.0 milestone Jul 22, 2024
@enebo enebo merged commit cf7cac0 into jruby:9.5-dev Jul 22, 2024
@enebo enebo deleted the api_changes2 branch July 22, 2024 18:05
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