[Samuele Pedroni] > care to suggest a cheap way to get such a unique integer that's > not the address. I'd love to, but don't know enough about Java to guess. > ... > otherwise I see no other way than keeping a weak identity mapping > from objects to integral type values, the aforementioned unique > integers. Then is there a reason not to do that? Presumably only objects to which id() is actually applied need to become keys in such a mapping, and if so only id() users pay the price. > Likely using a type for which a counter to get fresh unique > integers cheaply will not overflow too quickly. If it's a weak-keyed dict you could also reuse the integer values associated with keys that go away. > Or instead of the mapping attach such integrals value to each > object. The latter is not an option for Jython, because we cannot > attach things to general Java objects we have to deal with. Then why bring it up <wink>? Note that I don't object to introducing a mechanism that copy etc can use that's highly efficient under all implementations. But the introduction of such a mechanism isn't sufficient reason to get rid of the current id(), even if id() is horridly expensive in some implementations.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4