On Saturday, 25 July 2015 at 03:11:59 UTC, Walter Bright wrote:
On 7/24/2015 7:28 PM, Jonathan M Davis wrote:
I confess that I've always thought that QueryInterface was a
_horrible_ idea,
Specifying every interface that a type must support at the top
of the hierarchy is worse. Once again, Exception Specifications.
Well, in most code, I would think that you should be getting the
actual object with its full type and converting that to an
interface to use for whatever you're using rather than trying to
convert something that's one interface into another. It usually
doesn't even make sense to attempt it. So, the only place that
has all of the functions is the actual class which _has_ to have
every function that it implements. I certainly wouldn't argue for
trying to combine the interfaces themselves in most cases, since
they're usually distinct, and combining them wouldn't make sense.
But similarly, it doesn't usually make sense to convert on
interface to a totally distinct one and have any expectation that
that conversion is going to work, because they're distinct.
Most code I've dealt with that is at all clean doesn't cast from
a base type to a derived type except in rare circumstances, and
converting across the interface hierarchy never happens.
I've never seen QueryInterface used in a way that I wouldn't have
considered messy or simply an annoyance that you have to deal
with because you're dealing with COM and can't use pure C++ and
just implicitly cast from the derived type to the
interface/abstract type that a particular section of code is
using.
But maybe I'm just not looking at the problem the right way. I
don't know.
I suspect that 3 or 4 years after concepts and traits go into
wide use, there's going to be a quiet backlash against them.
Where, once again, they'll be implementing D's semantics. Heck,
C++17 could just as well be renamed C++D :-) given all the D
senabtucs they're quietly adopting.
Well, even if concepts _were_ where it was at, at least D
basically lets you implement them or do something far more lax or
ad hoc, because template constraints and static if give you a
_lot_ flexibility. We're not tied down in how we go about writing
template constraints or even in using the function level to
separate out functionality, because we can do that internally
with static if where appropriate. So, essentially, we're in a
great place regardless.
On the other hand, if we had built template constraints around
concepts or interfaces or anything like that, then our hands
would be tied. By making them accept any boolean expression
that's known at compile time, we have maximum flexibility. What
we do with them then becomes a matter of best practices.
The downside is that it's sometimes hard to decipher why a
template constraint is failing, and the compiler is less able to
help us with stuff like that, since it's not rigid like it would
be with a concept supported directly by the language, but the
sheer simplicity and flexibility of it makes it a major win
anyway IMHO.
- Jonathan M Davis
