I consider that as terribly hard to maintain code. As soon as you move around statements, refactor things everything gets messed up. No thanks.
> On 01 September 2017 at 12:15 Maciej Izak <hnb.c...@gmail.com> wrote: > > > 2017-09-01 11:41 GMT+02:00 Stefan Glienke <sglie...@dsharp.org>: > > > Again you will cause unnecessary headaches because now your helper has the > > dependency of the builtin and the third party one. > > How would third party one and third party two implement them? They both > > probably would extend the builtin one. Which one can you use in your code > > then? > > Yes, the one that comes last in the uses. What if you want to use > > functions from both? Out of luck again. > > > > Inheritance regardless what form is never is the best option here. I think > > "ancestor list" is just a misnomer in the documentation as it cannot be a > > list but only one in case of class helper. > > > The control of modules order in uses section can turn programmers life into > real hell for type helpers. I think that new directive > $EXPLICITHELPERS should help : > > type > TH1 = record helper for string > procedure foo; > procedure foo1; > end; > > TH2 = record helper for string > procedure foo; > procedure foo2; > end; > > TH3 = record helper for string > procedure foo; > procedure foo3; > end; > > var > s: string; > begin > s.foo; // call TH3.foo > > {$EXPLICITHELPERS TH1 for string} // scope for helpers limited only to TH1 > s.foo; // call TH1.foo > s.foo3; // error > > {$EXPLICITHELPERS TH2, TH1 for string} > s.foo; // call TH2.foo > s.foo1; // call TH1.foo1 > > {$EXPLICITHELPERS default for string} > s.foo; // call TH3.foo > > {$EXPLICITHELPERS TH1, default for string} > s.foo; // TH1.foo > s.foo1; > s.foo2; > s.foo3; > end. > > -- > Best regards, > Maciej Izak _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel