In reply to a post by gomezz:

In reply to a post by RobertoS:

The people using or inheriting OOP code become wholly unaware of how it works, and so wholly unaware of how their adaptation can screw thing a few levels of inheritance up the tree

I think that is mostly when someone uses an object based on how it actually works rather than how it is supposed to work then gets caught out when the object behaviour is "corrected". Default behaviours are a popular sources of disasters in waiting.

Not sure why object inheritance is being singled out. But truly the biggest source of upgrade problems for any software component are dependencies on undefined behaviour in client applications.

For example an API call formally takes a value between 1 and 10 with all other values producing undefined results. Now some broken app comes along and passes 11 to the API. In v1.0 this might work just fine because the implementation of the API call caps values that are too large. Then v2.0 comes along, the defined API does not change, but an optimisation has been implemented to make the function faster. Now passing 11 to it causes a crash. The bug is in the app not the upgraded component. But naturally users are going to blame the component vendor, e.g. Microsoft, for breaking their apps.

Microsoft do go out of their way to minimise these kind of problems. It's in their financial interest to ensure upgrades go as smooth as possible. If a popular apps stop working it's a big problem for them not just the app vendor. There are literally thousands of workarounds built into Windows to enable broken apps to continue to function but they can't catch them all.

Why, if the defined range is 1-10, does any other value produce "undefined results"?

It should issue an error message and drop the call. It's up to the app if it doesn't cater for an error return.

There are literally thousands of workarounds built into Windows to enable broken apps to continue to function but they can't catch them all.

If an app breaks the standard, stuff it!

This sort of approach is idiotic, and inevitably gives rise to hassle all round. The app writers need to learn that they need to code correctly as well. You cannot program sloppily and expect your app to work.

You don't fudge an OS to process incorrectly formatted calls. You validate it and kick it out if it fails.

The only time that should give a problem is if in a later OS or version is if in the case here you reduce the range to 1-9. Even that isn't insurmountable at the design and specification stage.

Why, if the defined range is 1-10, does any other value produce "undefined results"? It should issue an error message and drop the call.

The principal reason for skipping input validation is performance. If validation is cheap then it will usually be done and documented. For example a function accepting a pointer to a complex data structure will normally return an error (or fake success) if the pointer is 0. But it will not validate the entire data structure before processing it. And so a pointer to an invalid data structure will usually crash the process (but might not by fluke -- that is, until Windows n+1 is released!).

This is reasonable behaviour for an OS level API, IMO. If certain applications need expensive data validation its up to them to provide it. It's not reasonable to degrade the performance of the operating system generally. Of course the OS can also provide helper functions and API validation tools to the application developers.

You don't fudge an OS to process incorrectly formatted calls. You validate it and kick it out if it fails.

In an ideal world maybe. But Microsoft have to sell Windows upgrades to people who depend on these apps. If the new Windows won't run their apps then Microsoft lose a sale.

The only time that should give a problem is if in a later OS or version is if in the case here you reduce the range to 1-9.

Microsoft will never make breaking changes to stable public APIs. It just doesn't happen. (Cue: some example where they did it.. OK they will rarely do it and even more rarely do it deliberately.)

Can you provide a list of software you have had any involvement in, so I can avoid it?

If you think something I wrote is incorrect then you should avoid all software.

There are literally thousands of workarounds built into Windows to enable broken apps to continue to function ....

If certain applications need expensive data validation its up to them to provide it. It's not reasonable to degrade the performance of the operating system generally.

Degradation of the performance of the OS generally is what the first quote causes.

Any data in the passed structure that is processed by the OS should be vetted by the OS. In this day and age, nothing an app does should in any way be able to damage the smooth running of an OS.

As for affecting performance by adding validation code, ye gods! With the power of even the lowest powered PC-level of processor for many years that is seriously not a factor.

As for your reliance on poorly written historic OS from Microsoft accepting grot, so by extrapolation the newer one must, where on earth does that end except in chaos? It becomes completely infeasible and produces low-performance code. Which brings us back to OOP. A flawed concept from day one for professional use in major systems.

Have you ever examined, (I expect you have, it's a rhetorical question), the object code produced from MS C++ and C# compilers? There can be dozens of instructions to set a single indicator, simply because of the levels of inheritance involved.

Oh! Wait! ....

Of course, it's Windows we are talking about . Chaos.

In reply to a post by Sark:

If you think something I wrote is incorrect then you should avoid all software.

No, I just need to avoid the stuff you wrote (or tested, designed, specified, managed, etc).

In this day and age, nothing an app does should in any way be able to damage the smooth running of an OS.

Indeed. Process isolation is one of the prime guarantees of the OS. If an app giving bad data to the OS does anything worse than crash the process it is a bug in the OS.

As for affecting performance by adding validation code, ye gods! With the power of even the lowest powered PC-level of processor for many years that is seriously not a factor.

Depends on the complexity of the data to be validated. If it's cheap it'll be done. Microsoft will make the trade off on a case by case basis.

As for your reliance on poorly written historic OS from Microsoft accepting grot

Well.. it's not just Microsoft that makes these trade offs. Try passing bad data to Linux system calls and see how far you get before your app crashes. Heck even easier try passing bad data to C standard library functions; they do almost zero validation.

Which brings us back to OOP. A flawed concept from day one for professional use in major systems.

I would take issue with that!

Have you ever examined, (I expect you have, it's a rhetorical question), the object code produced from MS C++ and C# compilers? There can be dozens of instructions to set a single indicator, simply because of the levels of inheritance involved.

Well it's what you make of it. C# is a much higher level language than C++. It'll do a lot more for you behind the scenes. It has its pros and cons.

Good luck!