On 23.02.2016 17:21, Serguei TARASSOV wrote: > Michael Van Canneyt wrote >> I hope you will send the same mail to embarcadero/Idera. >> When they added methods to TPoint, they broke have the VCL code ? >> >> To avoid this, we would need to freeze the code as soon as it is released. > > Compared with Unicode migration, introducing the methods into records is not > breaking :)
Adding methods to the TPoint or TRect record is *exactly* like adding a method/property to TField. If you use "with" you might find yourself in a dangerous/problematic situation. That *did* happen with various code after we introduced the new methods to TPoint and TRect. > The code is not frozen but for the core level units the modifications are > rare and very risky without vast codebase and testing. > DB is a vary mature unit, almost all DACs based on it so 100% compatibility > with Delphi does matter. And the DB code is Delphi compatible. But if you (as in "general you") are using a feature that is *known* to lead to problems if fields and properties are added then that's your own problem. From great power comes great responsibility. We take backwards compatibility very serious, but there has to be a line drawn somewhere. > However, there are some useful methods to extend: > - subclassing (the safest) > - class helpers > - property/method's attributes (need to be introduced at compiler level) > - interfaces (when creating new interface for every extension) And to burden everyone else with the need to e.g. include a unit with a helper restricting them from adding their own if they don't derive from the original helper? No thank you. We are no slaves to Delphi. Regards, Sven _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
