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 <ivankob4m...@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 <ivankob4m...@gmail.com>: >> directive to turn said optimization off >> ================== >> But everyone wants the optimization ! (sure without breaking >> consequences) >> >> >> 2012/7/22, Ivanko B <ivankob4m...@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.ma...@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@lists.freepascal.org >>>> http://lists.freepascal.org/mailman/listinfo/fpc-devel >>>> >>> >> > _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
