.NET overloads/shadows

[VectraMan]

Well, I wouldn't argue with much of that. Except for "and when the function doesn't exist in B". Since the client is calling B.Something I don't think it is entirely unreasonable to expect B.Something to be called.

B.Something will be called, if it exists. The compiler, when compiling the client end, looks for Something in B, doesn't find it, then looks for one in the base class, does find it, so inserts code to call that.

The other way it could work is for the compiler to write a stub for B.Something to call A.Something and every other function that might be overidden, just so that a future build of the B code could then override it. Which would obviously introduce a large overhead.

I guess what you're saying is you want that logic to exist at load time, not necessarily at runtime (like a virtual function). That means the loader needs to know about OOP and inheritance, which isn't really its job.

[ASB]

B.Something will be called, if it exists. The compiler, when compiling the client end, looks for Something in B, doesn't find it, then looks for one in the base class, does find it, so inserts code to call that.

B.Something will be called if it happened to exist at compile time. So yes in order to cope with it it would have to treat all functions as virtual.

But since it allows the overloading of non virtual virtual functions this does indeed mean all functions should be treated precisely this way.

Ultimate the compiler is trying to offer flexibility, just doesn't quite explain the implications.

[xoggoth]

Dunno, I am just about to release a new product using VB.net and it all works pretty well but I never undertand all that technical jargon about overloads and late binding etc.

[VectraMan]

But since it allows the overloading of non virtual virtual functions this does indeed mean all functions should be treated precisely this way.

Ultimate the compiler is trying to offer flexibility, just doesn't quite explain the implications.

I don't agree; the problem here is about Exes and DLLs, nothing to do with the compiler. Exactly the same would happen in C++.

[Weltchy]

There is no such command as overloads in C# (or rather, you have no need to use it). If you have the same method name but with a different interface in C#, the compiler automatically picks up the fact. The new class modifier keyword in c# essentially hides the base class's implementation of a method with the same interface and points towards the new method in the implementing class. I don't know what the equivalent keyword in VB is, although I think it might well be shadows.

[ASB]

although I think it might well be shadows.

Yes I think it is the equivalent. But I get exactly the same issue in VB. Have to recompile to client to notice.