[fpc-devel] Re: Class field reordering

[Marco van de Voort]

In our previous episode, Giuliano Colla said:
> > As far as Guiliano's suggestion goes, then I rather use a cmdline option for
> > that (when compiled with that option it is allows to access private fields),
> > rather than syntax.  (but I don't know if the PPU format actually contains
> > enough info to access private fields, so this is probably not easy).
> A command line option would make *all* private fields of *all* objects 
> fully visible. 

On a per unit basis maybe, but yes.

>A different class definition would make visible just a few selected
> classes.  It makes quite a difference.

Still, anything but syntax. Then directive. (though I still think cmdline is
enough)

> > But since it is apparently not worth discussing individual cases over, IMHO
> > that means it is not worth compiler changes either.
> There's an issue which isn't individual but general. Free software means 
> having the freedom of using it however you see fit for your application. 

Yes. But this is not about free software principles, since it applies to the
binary releases we create, not the source. If it was merely a source issue,
maintaining a set of patches would be easy.

And I'm still not convinced there really is a /general/ problem, as opposed
to a handful of crucial fields, and just trying to cut corners with due
process by taking the easiest way out.

Sure, there is a lot of sentiment flying around, but that is something
different that there really is an acknowledged problem.

> This applies to fpc itself, and to fpc based tools, like Lazarus, FPGui, 
> MSEide, MSEgui etc. If fpc offered a way to provide a higher degree of 
> freedom, it would be a general improvement of fpc.

More likely yet another time sync. Since we are talking issues here that do
not appear to be worth filing mantis reports for.

> If it were done properly it could keep all the advantages of stable
> guaranteed API's with the flexibility required by a large number of
> individual cases, which, taken one by one, would be almost impossible to
> cope with.  Taken as a group they make a general case, worth considering.

Not entirely the same. It would be if the people using these inofficial
interfaces only for their own purposes. But this is for projects that pass
it on. IOW people will start to base stuff that is based on stuff that is
based on volatile interfaces.