Rant after trying Rust a bit

Paulo Pinto via Digitalmars-d digitalmars-d at puremagic.com
Sat Jul 25 03:27:47 PDT 2015


On Saturday, 25 July 2015 at 10:12:15 UTC, Jonathan M Davis wrote:
> On Saturday, 25 July 2015 at 09:44:30 UTC, Jacob Carlborg wrote:
>> On 2015-07-24 21:04, Walter Bright wrote:
>>
>>> Dynamic cast is no different from QueryInterface(), which is 
>>> how it's
>>> done, and the reason is the point of all this - avoiding 
>>> needing to
>>> enumerate every interface needed by the leaves at the root of 
>>> the call
>>> tree.
>>
>> I'm not familiar with QueryInterface():
>
> It's part of COM. Basically, it's equivalent to doing something 
> like
>
> auto f = cast(MyInterface)myObj;
> if(f is null)
> { /+ you can't convert it to MyInterface +/ }
> else
> { /+ you _can_ convert it +/ }
>
> except that with the way that QueryInterface works, it's 
> actually possible to get a completely different object out of 
> it. It doesn't have to have any relation to the original 
> object, and the new type doesn't have to be in an inheritance 
> hierarchy with the original type. So, you can do wacky stuff 
> like have an interface which relates to one object hierarchy 
> and convert it to an interface from a completely unrelated 
> object hierarchy just so long as the underlying type knows how 
> to give you the type you're asking for (be it because it 
> implements both interfaces or because it's designed to give you 
> an object that implements the interface you're asking for).
>
> So, QueryInterface isn't actually guaranteed to do anything 
> like a cast at all. It just guarantees that you'll either get 
> an object of the type you ask for - somehow - or that the call 
> will fail.
>
> And the way it's used often seems to be the equivalent of 
> something like
>
> interface A {}
> interface A : B {}
>
> interface Foo {}
> interface Bar : Foo {}
>
> class MyClass : B, Bar {}
>
> Foo f = getFoo(); // returns what it is actually a MyClass
> A a = cast(A)f;
>
> It happens to work, because the underlying type implements 
> both, but why on earth would you expect that a Foo would be 
> related to an A when they're completely unrelated? And yet that 
> seems to be the sort of thing that gets done with 
> QueryInterface - at least in the code that I've worked with 
> that does COM.
>
> Personally, I think that it's nuts to even be attempting to 
> cast from one interface to an entirely unrelated one and expect 
> it to work - or to write code in a way that that's a normal way 
> to do things.
>
> - Jonathan M Davis

It makes sense when one thinks about pure interfaces and 
component oriented programming, as preached by one of the 
Component Pascal guys. Or for that matter how Go uses interfaces.

The problem is when people try to model classical OOP on top of 
COM. This is one reason why on WinRT all classes implementing COM 
are required to be final.


More information about the Digitalmars-d mailing list