Hi,
Stephan Bergmann wrote: [...]
I think there are four possible ways out of this dilemma:
1 Leave the current implementation untouched, and do not incorporate Daniel's fix. This would be unfortunate, as the current implementation violates an important design invariant of >>=.
Agreed.
2 Incorporate Daniel's fix as is. This would be unfortunate, as the results are unnatural and error-prone, as detailed above.
Agreed.
3 Incorporate Daniel's fix and change the rules so that extracting a null reference of interface type T1 to a reference of interface type T2 succeeds if and only if T1 is derived from T2. That is, the list would become
b1: false x1: unmodified b2: true x2: null b2a: true x2a: null b2b: false x2b: unmodified
This fits the model that the checking done in Any is mostly based on static types.
4 Incorporate Daniel's fix and change the rules so that extracting a null reference of interface type T1 to a reference of interface type T2 always succeeds, independent of T1 and T2. That is, the list would become
b1: true x1: null b2: true x2: null b2a: true x2a: null b2b: true x2b: null
In that case it would be consequential to solve the original problem in an entirely different way: Keep setting the extracted value to null for any reference->reference extraction, but return true in all cases (as a value was extracted). Due to the existence of null references the return value of operator >>= is not sufficient to determine whether a valid interface was obtained. But that is what decides whether queryInterface can be considered successful or not.
Making the success of extraction depend on the contained value rather than only its type is counter to the way this operator works for other types. If you do this, you might as well make the success of narrowing extraction of numeric types depend on the actual value (i.e. whether the extraction is lossless for that particular value).
I favor the fourth solution, and would suggest implementing it for OOo 2.0, even though it has the slight potential of breaking existing code (as some of the b's would change).
Of course my suggestions would change even more b's - and are very likely to break existing code - so they are rather inappropriate at this time in the release cycle :-/
Ciao, Joerg
-- Joerg Barfurth Sun Microsystems - Desktop - Hamburg >>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<< Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
