Hijacking

[Chris Nicholson-Sauls]

Walter Bright wrote:
> I want to continue a bit in the Overloading/Inheritance thread which is 
> getting a little long, on a closely related issue which I find to be 
> important, but so rarely referred to that I had to come up with a name 
> for it - hijacking.
> 
> Hijacking is when code A depends on B, and then when seemingly unrelated 
> code C is modified, then A's behavior silently changes. Here's an 
> example from C++:
> 
> --A.h--
> void foo(long i);
> 
> --B.c--
> #include "A.h"
> #include "C.h"
> ...
> foo(3);    // calls A's foo(long)
> --------
> 
> Let's say A.h and C.h are developed by different people. In C.h, the 
> developer adds:
> 
> --C.h--
> void foo(int i);
> -----
> 
> This does something completely different from A.h's foo(long), because 
> they just happened to share the same name. Now, when B.c is recompiled, 
> it's call to foo is silently *hijacked* by C.h's foo.
> 
> Because of C++'s overloading rules and lack of modularity, there's no 
> way to programmatically defend against this. Instead, one has to rely on 
> coding conventions (such as using a unique package prefix name on all 
> symbols, like A_foo() and C_foo()).

Thank the heavens for D's modules and FQN's.  :)  You've got that 
situation covered.

> So how does this relate to the overloading/inheritance issues? Consider:
> 
> ----A.d----
> class A
> {
>     ...
> }
> -----B.d----
> import A;
> class B : A
> {
>     void foo(long);
> }
> ...
> void bar(B b)
> {
>     b.foo(3);   // calls B.foo(long)
> }
> ----
> 
> Let's say A.d comes from some third party library. Now the developer of 
> A decides to add some functionality to class A, and adds the member 
> function foo(int):
> 
> ----A.d---
> class A
> {
>     void foo(int);
> }
> ------------
> 
> Now our hapless B programmer has his calls to B.foo(long) silently 
> hijacked to A.foo(int) (under Java rules). I don't see any reasonable 
> way for B to defend against this. Certainly, developer A doesn't have 
> any idea who is deriving from A (and that's the point of polymorphism) - 
> but should he be disallowed from adding *any* method names? And the 
> hapless B developer, he wrote class B years ago and no longer quite 
> remembers how it works, he just recompiles it and now it silently fails.
> 
> So, this is one case where I feel C++ got it right, and Java didn't.
> 
> (P.S. It's not a compiler implementation issue, nor is it a runtime 
> performance issue.)

Alright.  I can't argue against that one little bit.  I will mention for 
completeness the option of using an L suffix to explicitly state you 
want a long... but then there's no analog for explicit int/short/byte, 
so the problem still exists in any case other than ambiguity against 
long.  (Yes there's cast()... but ew.)

-- Chris Nicholson-Sauls