[fpc-devel] Re: Class field reordering

Ivanko B ivankob4mse2 at gmail.com
Sun Jul 22 11:32:53 CEST 2012


directive to turn said optimization off
==================
But everyone wants the optimization ! (sure without breaking consequences)


2012/7/22, Ivanko B <ivankob4mse2 at gmail.com>:
> Asking for changes to make base classes more flexible is not bothering
> us. It's a regular part of software development, and in the best case
> every user of FPC comes out ahead in the end thanks to the resulting
> changes.
>
>  Hacking around the type system that results in certain optimizations
> becoming impossible is annoying, however. And I don't really see a
> best case outcome in this case, regardless of what is done in the end.
> ==============================
> Hmm..it sounds like "Relaxing access rights is a usual deal and why
> shouldn't we do it again to resolve the contradictions - especially if
> it turns out to be the only relevant ?" :)
>
>
> 2012/7/22, Jonas Maebe <jonas.maebe at elis.ugent.be>:
>>
>> On 22 Jul 2012, at 11:09, Martin Schreiber wrote:
>>
>>> 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.
>>
>> Asking for changes to make base classes more flexible is not bothering
>> us.
>> It's a regular part of software development, and in the best case every
>> user
>> of FPC comes out ahead in the end thanks to the resulting changes.
>>
>> Hacking around the type system that results in certain optimizations
>> becoming impossible is annoying, however. And I don't really see a best
>> case
>> outcome in this case, regardless of what is done in the end.
>>
>>
>> Jonas
>>
>> PS: just to make it clear, I haven't committed this optimization
>> yet._______________________________________________
>> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
>> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>>
>



More information about the fpc-devel mailing list