Thorsten Behrens wrote:
Frank Schönheit - Sun Microsystems Germany <[EMAIL PROTECTED]> writes:
Sure, the need to enforce API
constraints programmatically is still a valid point, e.g. a method
returning a null reference though the API stated the returned ref is
never null has to lead to a RuntimeException.
But I rather would like this decoupled, e.g.
Reference<foo::XBar> x(y->baz()[, UNO_QUERY]);
assureNotNull(x);
IMO more verbose, but clearer to read.
[...]
I don't like the additional line. That's basically how it's done today,
and this really becomes cumbersome over time. Writing the same pattern
again and again isn't really fun.
I think this is more about readability, and not about writability. And
since code is read more often than written, I second Daniel's
opinion. Which quite nicely brings us back to that ole error
reporting/assertion cleanup/are-RuntimeExceptions-permitted-to-catch
topic, as I pretty much assume assureNotNull is meant to assert
something in a debug build. We should really, really start thinking
about that now...
Cheers,
I think readability of the UNO_QUERY_THROW stuff is ok. I think there
are two main uses of the UNO query stuff: query to see if some
(optional) interface is available at an object (in which case NULL is
ok), and query to walk from one interface of an object to another
(mandatory) one (in which case NULL is not ok). Both uses are so common
that we should have short, easy idioms for them, and I think the two
Reference ctors (without and with UNO_QUERY_THROW, respectively) fulfill
this need more or less well.
So, I tend to agree with Frank and Kay rather than Daniel and Thorsten.
Back to Frank's original question (of introducing UNO_SET_THROW), I'm
somewhat undecided:
On the one hand, I think we should keep it simple, so go with
Reference<T>(x, UNO_QUERY_THROW) also in cases where x is already of
type T but should just be NULL-checked. Easy idiom (and I guess each of
us discovered it on his own once UNO_QUERY_THROW was introduced, so I do
not consider the idiom non-obvious).
On the other hand, performance *could* be a problem (in remote
scenarios). (If the original UNO design would have used something other
than "query(XInterface) == query(XInterface)" for object identity check,
we could improve performance of the Reference<T>(Reference<T> const &,
UNO_QUERY_THROW) by special-casing it.)
So, not sure if we are talking about premature optimization or premature
pessimization. For what it's worth, I used this NULL-check issue quite
often and never worried about performance...
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
