To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=83863
------- Additional comments from [EMAIL PROTECTED] Wed Dec 12 10:48:04 +0000 2007 ------- Whether or not the internal object is the same is an implementation detail unknown (and irrelevant) to users of the UNO interface (The whole point of having an "interface" is to insulate against implementation details). The justification for using generateOID()/areSame() instead of hashCode()/equals() is that proxies can change. This is documented. The UnoRuntime methods exist to deal with this. But while it's documented that you can get different proxies to the same object, nowhere have I seen it documented that the objects themselves can change identity without being touched (in the extreme case even in a read-only document). Fact is that from the outside the image is always the same. It's never modified during the test. An outside observer has every right to expect that it will keep its ID. I claim that every single user of the UNO interface outside of the inner circle of developers actually working on and aware of the internals of OOo will expect my test case to create constant OIDs. The documentation says: "The methods generateOid, queryInterface and areSame delegate calls to the implementing objects and are used instead of hashCode, casts, instanceof, ==, and equals" "[generateOID()] Generates a world wide unique object identifier (OID) for the given object. It is guaranteed that subsequent calls to this method with the same object will give the same ID." I think there can be no argument about what this means. If generateOID() cannot be used as a reliable replacement for hashCode() it violates the above interface description (which is what UNO developers work from) and loses its usefulness. If you cannot make it work as specified, it would be better to have it throw a RuntimeException in cases where the OID has been lost than to silently return inconsistent results. This will at least fail fast and alert application developers of the problem and save them a long an tedious bug hunt to find the reason for strange and inconsistent behaviour of their application. But I think it must be possible to fulfill the contract. After all, the image is not changed. Assuming that OOo's internal memory management does not perform defragmentations or something like this, it's probably stored at the same memory location all the time. So that could be used to generate an OID. Alternatively a unique ID could be generated on allocation and attached to the data structure holding the object data. That would survive even moves within memory. For objects that have a unique name already (like images), the OID could be generated based on that. This would mean that renaming the image would change the OID, which is still unexpected IMHO, but preferable to the current situation. At least it's a transparent behaviour that can handled by implementors (if properly documented). Unfortunately this does not work for general shapes since their names are optional and non-unique. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
