On 21/07/2012 16:55, Ivanko B wrote:
The problem now is that cracker classes can't be used in future anymore because of the new class field ordering optimisation, so I dared to ask.
....
So, is it possible to design the new feature in such way that to have an option to proceed using cracker classes ?
But the whole discussion comes down to one other simple question. Including the above, the whole discussion is about:
Should FPC provide a way to access private fields from any other code? The same dilemma in expressed by: On 14/07/2012 20:46, Jonas Maebe wrote:
That may actually lead to quite some troubles: if someone recompiles the RTL without optimizations, then your class crackers also have to change that setting. And there's no way to detect how the RTL (or in general: units containing classes you are "cracking") has been compiled in your source code. Adding support for something like that is definitely not a road I want to go down -- even a switch to simply treat all "private" fields as "protected" would be less bad (not that I would consider such a switch desirable in any way; it's like adding a switch to allow calling functions only declared in the implementation of another unit).
In context of the discussion, if such an optimization can go ahead, or if it would break (valid) code. Jonas says the following (or I read it into it): 1) Support for accessing private fields as if they where protected is not an option 2) Yet he discusses the option of holding back class re-ordering optimization.
And 2 is (so far) only for the point of allowing cracker classes (in other words: access to private fields). So in entering the discussion for 2, it seems to me he is in direct contradiction of 1?
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
