[ruby-core:90505] [Ruby trunk Feature#15408] Deprecate object_id and _id2ref

[shevegen@gmail.com]

Issue #15408 has been updated by shevegen (Robert A. Heiler).


I originally wanted to write a very long reply but I think it becomes too difficult
to keep track of what is being said, so just my opinion in a somewhat more condensed
form than before:

- I have no strong opinion on _id2ref. I think I used it only once or twice in 13 years.

- I am not convinced that .object_id should be removed. We would lose some introspection
here, wouldn't we?

I would recommend to postpone deprecation after ruby 3.x IF it is decided to remove 
object_id. But I am not convinced that it should be removed - it is not only a question
of implementation details, or how people use it "incorrectly", but it is whether we
should be able to query object ids, find them in ObjectSpace etc...

I would suggest this to ask matz in an upcoming developer meeting since part of the
question is the intent of how matz may suggest or think that ruby users may use
object_id. I don't have much code that relies on object_id, so an any change would
not affect me that much - but I am in disfavour of removing it eventually without
really knowing what the alternatives are. Or whether we would just lose functionality
without any real gain, with which I would disagree very strongly. So my own opinion
is much closer as to what spatulasnout wrote.

PS: It is a bit difficult to reason in pro/con when it comes to "incorrect" usage
of ruby code. Ultimately the parser allows something or does not; and how matz 
designed ruby + ruby's philosophy plays in, which of course determines what the
parser allows (compare to python requiring () for method calls and ruby not
"caring" that much, unless it is ambiguous). Anything aside from that is heavily
subject to a personal opinion, and this becomes difficult to reason about.

The world is not going to end if object_id is removed; but it is not going to
end when object_id remains, either.

For sake of completion, I would also like to point out that the pickaxe mentioned
object_id several times, so I assume quite some people know and have used object_id
(and probably not many used _id2ref); and the name used to be .id if I recall
correctly before it was changed to object_id. But anyway, I highly recommend to
have this be discussed some time in 2019 at a developer meeting.

PSS: Perhaps for alternatives, such as WeakMap, it could be tested extensively,
perhaps as a separate gem, if only to provide a proof-of-concept.

----------------------------------------
Feature #15408: Deprecate object_id and _id2ref
https://bugs.ruby-lang.org/issues/15408#change-75663

* Author: headius (Charles Nutter)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
Ruby currently provides the object_id method to get a "identifier" for a given object. According to the documentation, this ID is the same for every object_id call against a given object, and guaranteed not to be the same as any other active (i.e. alive) object. However, no guarantee is made about the ID being reused for a future object after the original has been garbage collected.

As a result, object_id can't be used to uniquely identify any object that might be garbage collected, since that ID may be associated with a completely different object in the future.

Ruby also provides a method to go from an object_id to the object reference itself: ObjectSpace._id2ref. This method has been in Ruby for decades and is often used to implement a weak hashmap from ID to reference, since holding the ID will not keep the object alive. However due to the problems with object_id not actually being unique, it's possible for _id2ref to return a different object than originally had that ID as object slots are reused in the heap.

The only way to implement object_id safely (with idempotency guarantees) would be to assign to all objects a monotonically-increasing ID. Alternatively, this ID could be assigned lazily only for those objects on which the code calls object_id. JRuby implements object_id in this way currently.

The only way to implement _id2ref safely would be to have a mapping in memory from those monotonically-increasing IDs to the actual objects. This would have to be a weak mapping to prevent the objects from being garbage collected. JRuby currently only supports _id2ref via a flag, since the additional overhead of weakly tracking every requested object_id is extremely high. An alternative for MRI would be to implement _id2ref as a heap scan, as it is implemented in Rubinius. This would make it entirely unpractical due to the cost of scanning the heap for every ID lookup.

I propose that both methods should immediately be deprecated for removal in Ruby 3.0.

* They do not do what people expect.
* They cannot reliably do what they claim to do.
* They eventually lead to difficult-to-diagnose bugs in every possible use case.

Put simply, both methods have always been broken in MRI and making them unbroken would render them useless.



-- 
https://bugs.ruby-lang.org/