[fpc-devel] Re: Class field reordering

[Michael Van Canneyt]

On Sun, 22 Jul 2012, Martin Schreiber wrote:

> On Sunday 22 July 2012 10:52:33 Michael Van Canneyt wrote:
>
>>> "Numbers", not count. I want to know which bugs are worked around by
>>> crackers.
>>
>> That's easy: 0 bugs.
>>
> Sorry, there where bugs in the past and there probably will be in the future.

There are always bugs. We fix those as soon as we can.

Florian is talking about bugs you fix with cracker classes.

What bug do you solve with the TField stuff ? None. 
You work around a limitation, yes. But a limitation is not a bug.

>> Martin needs the crackers for some mse* features.
>>
> Which otherwise can't be implemented without changes in FPC or FCL.
> I don't dare to ask for changes so cracker classes were a workaround without
> to bother FPC team.

That's because you don't just ask for changes. 
You ask for your own solutions to be implemented in FPC.

Alternatives we present are discarded as sub-optimal or not to your liking.
Let me recapitulate:

1. You reject my solution for TField.
2. For TCollection.FItemClass I presented an alternative for your problem.
3. TParam.Bound turned out not to be a problem at all.

So, 
* 1 case which is not a problem. 
* 2 cases where you have been presented with a solution,
   but which you chose to reject. You can't blame us for that.

As for the TComponent and TStream problem cases, I am still waiting to see 
what bugs (if any) you want to solve:
You failed to give detailed descriptions so far.

Cooperation works in 2 directions. I'm willing to think about solutions. 
You must give detailed descriptions of what you think is a problem,
and be prepared to accept solutions that are maybe not 100% to your liking.

If you are not prepared to accept such solutions, then I cannot help you.

Michael.