[fpc-devel] Re: Class field reordering

[Ivanko B]

So, there're the following solutions which meet the requirements of
optimization & not breaking non-mainstream code & no need to custom
build FPC:

1) moving related fields from private to protected or even public
(makes the current classes structure more vulnerable)

2) creating protected "brother" properties for related private fields
( less appealing than "1)"  = people using them knows what they do )


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