Re: [udk-dev] cpp uno: Enhancement for uno::Reference
Thorsten Behrens wrote: Stephan Bergmann [EMAIL PROTECTED] writes: That is, from my side: go ahead. Hi Stephan, all, well, finally got around doing just that. Issue http://www.openoffice.org/issues/show_bug.cgi?id=72499 contains a patch, that adds said functionality, and addresses a few ambiguities/incomplete types across OOo. Thorsten, I saw your patch yesterday and only had a quick glance at it. What I do not understand is whether those few ambiguities/incomplete types across OOo are related to the Reference change (i.e., whether the Reference change introduces an incompatibility that has to be taken care of at those various places across OOo---that would be a clear no no). -Stephan Any objections, or shall I proceed? Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] cpp uno: Enhancement for uno::Reference
Stephan Bergmann [EMAIL PROTECTED] writes: I saw your patch yesterday and only had a quick glance at it. What I do not understand is whether those few ambiguities/incomplete types across OOo are related to the Reference change (i.e., whether the Reference change introduces an incompatibility that has to be taken care of at those various places across OOo---that would be a clear no no). Hi Stephan, no, this ain't an incompatibility in the sense of the word, although without the changes, compilation would break. Basically, removing operator const Reference XInterface unearthes various places, where the source type (that of the referenced interface being implicitely casted) is incomplete, or where the conversion to XInterface is ambiguous (people who do multiple inheritance). The former borders to a bug, the latter is inconvenient - although I suspect that the underlying reason for people passing around generic XInterfaces (and later querying for the actually needed one again) is at least partially related to uno::Reference having _only that one_ single automatic conversion in the past. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] cpp uno: Enhancement for uno::Reference
Thorsten Behrens wrote: Stephan Bergmann [EMAIL PROTECTED] writes: I saw your patch yesterday and only had a quick glance at it. What I do not understand is whether those few ambiguities/incomplete types across OOo are related to the Reference change (i.e., whether the Reference change introduces an incompatibility that has to be taken care of at those various places across OOo---that would be a clear no no). Hi Stephan, no, this ain't an incompatibility in the sense of the word, although without the changes, compilation would break. Basically, removing operator const Reference XInterface unearthes various places, where the source type (that of the referenced interface being implicitely casted) is incomplete, or where the conversion to XInterface is ambiguous (people who do multiple inheritance). The former borders to a bug, the latter is inconvenient - although I suspect that the underlying reason for people passing around generic XInterfaces (and later querying for the actually needed one again) is at least partially related to uno::Reference having _only that one_ single automatic conversion in the past. So it *is* an incompatible change (correct code that did compile now fails to compile). I could live with the consequences of this change, however. -Stephan Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] cpp uno: Enhancement for uno::Reference
Thorsten Behrens wrote: Stephan Bergmann [EMAIL PROTECTED] writes: I saw your patch yesterday and only had a quick glance at it. What I do not understand is whether those few ambiguities/incomplete types across OOo are related to the Reference change (i.e., whether the Reference change introduces an incompatibility that has to be taken care of at those various places across OOo---that would be a clear no no). Hi Stephan, no, this ain't an incompatibility in the sense of the word, although without the changes, compilation would break. Basically, removing operator const Reference XInterface unearthes various places, where the source type (that of the referenced interface being implicitely casted) is incomplete, or where the conversion to XInterface is ambiguous (people who do multiple inheritance). The former borders to a bug, the latter is inconvenient - although I suspect that the underlying reason for people passing around generic XInterfaces (and later querying for the actually needed one again) is at least partially related to uno::Reference having _only that one_ single automatic conversion in the past. Cheers, -- Thorsten To avoid problems with places where an otherwise ambiguous upcast from XWhatever to XInterface (i.e., where XWhatever uses multiple inheritance) used to work via the removed Reference::operator, would it make sense to specialize the new copy constructor/operator = member templates for the special case Ifc=XInterface? Just a thought. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] cpp uno: Enhancement for uno::Reference
Thorsten Behrens wrote: Stephan writes: I vaguely remember having discussed this before with Daniel Bölzle, but neither of us can remember whether there were any serious problems with it. Well, will of course try this on a full build ;-) Whether or not the constructor should be explicit might be a question of style, however. Don't think so. To match behaviour of plain ptrs (for the implicit conversion), the copy constructor needs to be non-explicit. After all, having that taking place automatically is my whole point here. I do not think that the situation is that simple. In my opinion, there are three possibilities, not two: First, the current situation where you have to use the potentially expensive ReferenceXBase(xDerived,UNO_QUERY_THROW) or the non-obvious, abstraction-breaking xDerived.get() or ReferenceXBase(xDerived.get()) to up-cast from XDerived to XBase. Second, the explicit option where you have to use the explicit ReferenceXBase(xDerived) for the up-cast. Third, the implicit option you proposed where you can implicitly use xDerived for the up-cast. That the third most closely mimics plain pointers does not automatically qualify it as the best solution. Too much implicit conversion can make code too obscure and fragile, as we probably all have learned the hard way. -Stephan [...] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] cpp uno: Enhancement for uno::Reference
Stephan Bergmann [EMAIL PROTECTED] writes: Third, the implicit option you proposed where you can implicitly use xDerived for the up-cast. That the third most closely mimics plain pointers does not automatically qualify it as the best solution. Too much implicit conversion can make code too obscure and fragile, as we probably all have learned the hard way. This statement is as true in general as is doesn't apply to this case. The only thing the proposed change will facilitate is the implicit upcast a naked ptr-to-interface has offered since ages. All of us should be used to that behaviour, have employed it countless times, and found it convenient (I for myself did, at least). This is in no way comparable to e.g. the automatic conversions of ints to strings, where semantics really get obscured. Cheers, -- Thorsten If you're not failing some of the time, you're not trying hard enough. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] cpp uno: Enhancement for uno::Reference
Thorsten Behrens wrote: Stephan Bergmann [EMAIL PROTECTED] writes: Third, the implicit option you proposed where you can implicitly use xDerived for the up-cast. That the third most closely mimics plain pointers does not automatically qualify it as the best solution. Too much implicit conversion can make code too obscure and fragile, as we probably all have learned the hard way. This statement is as true in general as is doesn't apply to this case. The only thing the proposed change will facilitate is the implicit upcast a naked ptr-to-interface has offered since ages. All of us should be used to that behaviour, have employed it countless times, and found it convenient (I for myself did, at least). This is in no way comparable to e.g. the automatic conversions of ints to strings, where semantics really get obscured. As I wrote before, I consider this kind of a style issue in this case and could probably live with both solutions. That is, from my side: go ahead. -Stephan Cheers, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] cpp uno: Enhancement for uno::Reference
Stephan writes: I vaguely remember having discussed this before with Daniel Bölzle, but neither of us can remember whether there were any serious problems with it. Well, will of course try this on a full build ;-) Whether or not the constructor should be explicit might be a question of style, however. Don't think so. To match behaviour of plain ptrs (for the implicit conversion), the copy constructor needs to be non-explicit. After all, having that taking place automatically is my whole point here. Frank writes: As much as I appreciate convenience while writing code, I never felt too bother with using the .get()-workaround. Granted. My point was that the workaround is non-obvious, to the best of my knowledge nowhere documented, and it breaks the abstraction of uno::Reference being a ptr-like object. On the other hand, I somewhat fear the zillion lines of output probably emitted by the compiler when it comes to an assigment xFoo = xBar where XBar is *not* a base class of XFoo, but the compiler nonetheless tries to match the several hundred potential assignment instantiations. Which makes me reluctant to this change ... Well, that's only 'your' Windows compiler stupidness - and it does that nevertheless, with that stdexcept spillage... ;-) No, seriously, in this case there's no trying-out of template instantiations. The types of xFoo and xBar completely and sufficiently determine the member template instantiation - the place that fails is the ptr assignment inside that template. So, if there are no hard objections, I'd implement the change, do a full build on my favorite platform, and report back with a complete patch here. Cheers, -- Thorsten If you're not failing some of the time, you're not trying hard enough. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
