On Thu, Aug 21, 2014 at 1:58 AM, Paolo Bonzini <[email protected]> wrote: > Il 20/08/2014 11:07, Peter Maydell ha scritto: >> The other thing you need to say is that the returned string is >> only valid for as long as the object remains a child property >> of its parent. (Is that right? I'm not clear. It also sounds like >> a really awkward lifetime management requirement, which >> suggests to me that really the "return-a-copy" semantics are >> nicer.) > > They are indeed nicer, but harder to use in C. > > Unparenting is (currently) always done under the BQL, so guaranteeing > that the returned string stays alive as long as you use it is currently > not a problem. This might change in the future, but I don't see many > reasons to get rid completely of the BQL (as opposed to the surgical > moving of stuff outside it that we've been doing so far). > >> Having object_get_canonical_path_component() and >> object_get_canonical_path() having different return value >> ownership semantics is likely to be a bit confusing I think. > > Right, though that could be solved by renaming the _component() function. >
Yes that had crossed my mind too. object_get_canonical_path_component is a mouthful and it's usages suggest object_get_name or object_get_instance_name would be more fitting. The fact that it is a canonical_path_component is more of an implementation detail rather than its externally useful functionality. Regards, Peter > Paolo >
