[fpc-devel] Re: Class field reordering

[Jonas Maebe]

On 22 Jul 2012, at 19:52, Giuliano Colla wrote:

> IMHO a clean solution can be found at language level: if I declare
> 
> TMyclass = class(TWhatever)
> 
> then I just get the degree of visibility that the class designer has decided.
> 
> But if I declare (just an example, a better keyword can be found)
> TMyclass = subclass(TWhatever)
> then I get full visibility, all the private fields of TWhatever become just protected in TMyclass, and of course, I'm on my own. The designer is not bound to any contract, because I have explicitly decided to run the risk.

No just you, but anyone using your units also runs that risk. When you add a possibility to the language that makes it easier for people to just use a special keyword to hack around something rather than report a bug/feature request or redesign their code, they will simply use that keyword most of the time because it's the way of the least resistance. This means that as a compiler developer you encourage the creation of code that may break any time the compiler is upgraded.

Users of such code however don't care whether such problems are caused by FPC or by the developers of those units. They just notice that things suddenly break and if the creator of that original code has stopped maintaining it, they're stuck or have to dive in themselves to fix things. We already have a sufficient number of backward incompatibilities with every FPC release without encouraging people to write code that increases the chance of that happening. Not to mention that it wouldn't just happen with FPC-released code, but with any code (users of third party frameworks could do exactly the same thing with that framework code).


Jonas