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
