Hi Pertti,

Sounds right to me, otherwise why have inheritence or oop at all?? Wasn't this the same way VB (not VB.Net) handled things?

Bob

>Hi, Martin.
>
>Thank you for your response -- since you have clearly worked with .NET a lot more than I have, you have a much better understanding of it (warts and all), I'm sure.
>
>I am not really trying to compare or rank two different development platforms here. I'm just coming from a purely theoretical point of view with this, which of course has practical implications. It seems to me that unless there is a very good reason for it (and I can't see what that might be), this type of "static" inheritance that is going on here (implementation is fixed as soon as the the control is placed on the design surface and the code-behind is autogenerated) is wrong. I believe that a development system shouldn't mix approaches like this.
>
>I understand how the .NET visual designers work and how code is autogenerated as you drop controls etc. on a form. Most of that autogenerated code includes inheritance right within the code, too. So what would be the purpose or the reason for all of a sudden not implementing inheritance in ALL aspects of a control's autogenerated code?
>
>I am not an expert in OOP inheritance theory by any means (and don't desire to be), I approach these things from the practical, application development side. However, everything I have read about OOP inheritance seems to state very clearly that if you expose any PEMS in a parent class, all classes that inherit from it should change their appearance and or behavior accordingly without any additional work required from the developer, EXEPT for PEMs that have been overwritten somewhere along the inheritance chain. If this is the agreement, then .NET's font handling turns the "agreement" upside down -- , because now you have to overwrite .NET font properties and write some additional code in order to ensure proper inheritance. Or am I just completely missing something here?
>
>I am not a puritan when it comes to programming theories -- if a "dictatorial" theory constrains you too much or makes your life difficult just because it dictates that things must only be done a certain way, then you have to make some allowances for real life applications (SmallTalk is a good example of such a puritan language, for better and for worse, IMO). However, I strongly believe in consistency when implementing a development system . And in this case at least it seems to me that .NET breaks this cardinal rule of consistency and causes headache and hair loss (I smell a class action lawsuit here <bg>).
>
>Again, I'm not comparing or ranking different platforms, such as VFP and .NET. I have my own likes and dislikes about all of the development platforms and languages I have ever used, but consistency earns high points in my report card. While VFP in many areas is certainly an infuriatingly inconsistent language, its OOP implementation at least is extremly consistent, especially when it comes to inheritance. The rule is hard and fast: Change PEMs only if you want to modify or break strict inheritance. No exceptions. Conversely, to keep inheritance intact, don't touch any PEMs. No exceptions.
>
>
>Pertti
>
>
>>Inheritance in .NET is the same as in most other platform. The only thing getting in the middle here, and something you pretty early discover and have to understand, is how the designers work, as they generate code to support many things. I don't like the WinForm approach very much, but it is something you quickly overcome.
>>
>>This is not a showstopper or a deep little secret at all. There are plenty of examples in the MSDN docs and everywhere else about Visual Inheritance and the like. I remember in the early days of VFP having to explain to many folks how VFP inheritance worked and why you could get weird results because some annoyance in how VFP 3 handled the overwritten properties. This is much the same.
>>
>>As usual, the main issue is judging .NET from a very VFP-centric perspective. There are many things that sound silly or wrong for a VFP developer, until you get used to them, understand the logic, and sometimes you realize it is more flexible, much better, or actually silly... 8-) Every platform has its quirks, and a huge one like .NET have many, but it is nothing compared to its strengths.
>>
>>Just for the record, if you need to build smart-client (non-browser based apps) in .NET at some point, I'd jump right to WPF instead of WinForms. This is an absolutely better model imho, and one you would surely love.
>>
>>Regards,