Feature #19998
closedEmit deprecation warnings when the old (non-Typed) Data_XXX API is used
Description
The replacement API was introduced in Ruby 1.9.2 (2010) [Feature #3064], and the old untyped data API was marked a deprecated in the documentation as of Ruby 2.3.0 (2015): https://github.com/ruby/ruby/commit/98544c372d948717de22afc86d162e411f1fb5f1
However, as of today, no deprecation warning of any sort is emitted when the API is used.
Ultimately removing the old untyped API would allow to easily reclaim 8B on every T_DATA
which could be used by the newly introduced embedded TypedData objects https://github.com/ruby/ruby/pull/7440
Was there any discussions about removing the old API at some point?
Could we emit a warning when the API is used? Either verbose or non-verbose, to at least surface the issue to gem owners? This would help drive the effort to fix outdated gems, allowing to eventually remove this old API in the future.
Looking at our big applications dependencies, there seem to be a small minority of gems still using the old API:
- https://rubygems.org/gems/unf_ext (https://github.com/knu/ruby-unf_ext/pull/72)
- https://rubygems.org/gems/rotoscope (https://github.com/Shopify/rotoscope/pull/99)
- https://rubygems.org/gems/re2 (https://github.com/mudge/re2/pull/116)
-
https://rubygems.org/gems/mysql2(use either API to support old rubies)
Migrating them over doesn't seem too hard.
Updated by Eregon (Benoit Daloze) 12 months ago
Maybe we should deprecate the corresponding C functions instead/in addition to runtime warnings?
i.e. the fix is in C extensions, not Ruby code.
+1 on deprecating those, it would simplify to have one (TypedData) instead of two data-like types.
Updated by byroot (Jean Boussier) 12 months ago
Maybe we should deprecate the corresponding C functions instead/in addition to runtime warnings?
Yes, I don't have a string opinion on the specific. I'm happy to implement whatever Matz decide.
Updated by rubyFeedback (robert heiler) 12 months ago
I do not have anything against the proposal itself, but in
regards to "This would help drive the effort to fix outdated
gems", I believe this to be slightly too optimistic. Many gems
that have not been updated in, say, 2-3 years, are probably
no longer (actively) maintained (for the most part). One can
see that on gems hosted on rubygems.org: many gems have one
peak activity of several releases, and then no more update
for years to come. So I believe the primary (better) argument
to be made should be rather in regards to "reclaim 8B on every
T_DATA" or deprecation handling in general (e. g. since as of
the year 2010) than assume adoption of older gems. If the ruby
devs communicate a strategy of change - and have given enough
time to adjust - then I think ruby should move forward towards
change (in general, that is; again, I don't have any particular
opinion on this issue; I don't think it affects me either way,
though of course reading "reclaiming xyz" sounds great - as matz
once said, nobody minds more speed/efficiency).
Updated by byroot (Jean Boussier) 12 months ago
Interesting tidbits from the re2
PR: https://github.com/mudge/re2/pull/116#pullrequestreview-1725029520
I was unaware of the newer TypedData API.
Which IMO confirms that just marking something as deprecated in the documentation has little effect, and some form of deprecation warning would help at least some gems upgrade.
Updated by naruse (Yui NARUSE) 11 months ago
Generally deprecation and migration takes development cost for gem developer.
Therefore such proposal needs to clearly shows the merit of the removal.
("marked as deprecated" is not such reason)
About the strategy of C API deprecation, runtime warning is not a good way because such warning make the gem unusable.
As byroot originally says first it should show a build time warning, then just remove the API is reasonable.
If the migration really has the benefit, gem owners should fix the usage.
Updated by byroot (Jean Boussier) 11 months ago
Therefore such proposal needs to clearly shows the merit of the removal.
I mentioned why I'd want it removed. It would allow to reclaim 8B per objects, allowing T_DATA
to be 32B rather than 40B, and we have plans to make slot sizes powers of two.
Updated by byroot (Jean Boussier) 11 months ago
But a build time warning at least would be a good way to prevent new gems from being written using that API.
Updated by ko1 (Koichi Sasada) 11 months ago
I agree to show build-time warning but I don't think we can remove T_DATA
feature.
Updated by byroot (Jean Boussier) 11 months ago
Alright. A big part of the API is composed of macros, so I'm not too sure how we can effectively make them emit a build time warning, but I'll see what I can do.
Updated by mame (Yusuke Endoh) 5 months ago
Discussed at the dev meeting. Matz accepted build-time warning.
However, the author of a gem that is not well maintained is not likely to notice the build-time warning. Whether it is actually possible to remove the APIs may require careful consideration in the future.
Updated by byroot (Jean Boussier) 5 months ago
Whether it is actually possible to remove the APIs may require careful consideration in the future.
Agreed. I'm not suggesting that yet. However I do have a proof of concept that degrades a bit the old API performance in favor of improving the new API performance, so having the API explicitly marked as deprecated help justify this kind of changes.
Updated by byroot (Jean Boussier) 5 months ago
- Status changed from Open to Closed
Applied in changeset git|fbb61a26e71be9faccb4ad2392e71d0a561854d1.
Mark old Data API as deprecated
[Feature #19998]