On 22 Jul 2012, at 12:40, Martin Schreiber wrote: > The situation here is especial because I must convince Michael for things > that > is of use for MSEgui only and most likely for no use in Lazarus or > contradicts his design principles.
I don't think "Lazarus doesn't need it" would be a valid argument to reject a proposed change. As to the design principles: > I learned that this situation is > unwinnable so I used mad workarounds with cracker classes instead. > Now I see that even moving private fields to protected is very difficult so I > will search for other solutions. The problem with making private fields more accessible is similar as with supporting cracking classes: it makes it much harder to change implementation aspects in the future without breaking anything. The whole point of encapsulation is to make it easier to change the implementation as necessary/desirable later on. This requires work to find the right encapsulation abstractions (which can relatively easily be changed in case the implementation is hidden, because then implementation changes won't hurt other uses), but it's the only way that is maintainable in the long run. > An API compatible MSEgui db.pas and MSEgui specific TComponent, TReader, > TWriter and other dependent classes is probably the best. I don't think it's the best. I'm also quite sure it will require more work from you in the long run, keeping them up to date and merging bug fixes and new features from FPC back into your fork. > AFAIK TObject is the only class which depends on compiler magic? Are there > other classes which can not be duplicated? Pretty much anything in the system and dialect units (objpas, macpas, objc, iso7185) is/can be(come) tightly bound to the compiler. The rest should be safe. Jonas_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
