[fpc-devel] Re: Class field reordering

[Ivanko B]

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.
==============
True but it relates to old issues, but there may be future issues
(subjects to wait until get fixed) - Martin, Graeme are mainly
bothered by them - whether it'll be possible to fix them in 1..2 days
(customer etc requirements) and in such manner that not to rebuild FPC
at developer's side.


2012/7/22, Ivanko B <ivankob4mse2 at gmail.com>:
> 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
>>>
>>
>