Well, despite my joy in finding a bug it seems that the issue of the overload polymorphism question is moot. Its a choice.
The compiler can choose to ignore the fact that a better parameter match exists and use a lazy evaluation of a method in a derived class. Apparently, this doesn't break the rules of OOP or of polymorphism. It just prevents "brittle base class" syndrome.
Personally, although I can see a certain validity in the arguments of MS gurus like Eric Lippert I still feel as though the wool has been pulled over my eyes somewhat. How I missed such a simple thing as this for the last eight years is a mystery to me. I must be getting old.
Ahh well. I suppose I had better brush up on my VB syntax because despite the fact that the language is verbose and redundant they have a kick-ass compiler that is proven to be better at
loop optimisation and now I discover that it handles an important compiler principle in a logical and intuitive way.
The compiler can choose to ignore the fact that a better parameter match exists and use a lazy evaluation of a method in a derived class. Apparently, this doesn't break the rules of OOP or of polymorphism. It just prevents "brittle base class" syndrome.
Personally, although I can see a certain validity in the arguments of MS gurus like Eric Lippert I still feel as though the wool has been pulled over my eyes somewhat. How I missed such a simple thing as this for the last eight years is a mystery to me. I must be getting old.
Ahh well. I suppose I had better brush up on my VB syntax because despite the fact that the language is verbose and redundant they have a kick-ass compiler that is proven to be better at
loop optimisation and now I discover that it handles an important compiler principle in a logical and intuitive way.
No comments:
Post a Comment