https://bugs.documentfoundation.org/show_bug.cgi?id=125421
--- Comment #9 from Wolfgang Jäger <[email protected]> --- (In reply to Mike Kaganski from comment #6) > We actually do create a new object each time a range object is requested > (see e.g. ScTableSheetsObj::GetObjectByIndex_Impl[1], which implements > functionality of XIndexAccess::getByIndex). So at least in case of range > objects (which have their range read-only, thus for all uses should be > considered "same" when refer to same range), ... ... we need some special casing to > check if they are objects of the same type (e.g., one could be "sheet", and > the other "all cells, but not sheet", ... ... and these are different objects), and > then refer to the same range. > > https://git.libreoffice.org/core/+/1c3eb7e329cd2eaeb83068907ba0c9a5b3ef7852/ > sc/source/ui/unoobj/docuno.cxx#3577 Thanks. I can't start to study and analyze the complex C++ code (I never understood sufficiently nor ever liked). As a frequent user of the API I would, however, expect that things are consistent to a degree allowing for a sufficient understanding either by a kind of self-explanation and educated reasoning or by well structured documentation. That there are objects of different types in a sense as underlying the above example without giving the user reliable information about it is just confusion, imo. I'm told that only service names are assured to be stable. OK. But if so there must be a service helping to distinguish "different object types" in every case. Otherwise implementation names must get assured stability, and must be applied in a way offering the mentioned functionality. Also a kind of bundling or "merging" services in a way that results in facts like EqualUNOobjects(cellObject, cellObject.Text)=True (same "object type"?) is evil if not at least there are reliable means to make the needed distinctions in a different way. An API will always partly be useless or create errors if its usage requires full understanding of the core code. If "object types" are actually defined by their BUNDLING of services, these types must have stable names, and their bundling (including the surprising "identities") must be documented. -- You are receiving this mail because: You are the assignee for the bug.
