Feature #19998
closed
Emit deprecation warnings when the old (non-Typed) Data_XXX API is used
Added by byroot (Jean Boussier) about 1 year ago.
Updated 6 months ago.
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:
Migrating them over doesn't seem too hard.
- Description updated (diff)
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.
- Description updated (diff)
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.
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).
- Description updated (diff)
- Description updated (diff)
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.
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.
But a build time warning at least would be a good way to prevent new gems from being written using that API.
I agree to show build-time warning but I don't think we can remove T_DATA feature.
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.
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.
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.
- Status changed from Open to Closed
Also available in: Atom
PDF
Like1
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by