Martin schrieb:
I am not sure what was required to be down striped, but I would be surprised if the reason for not doing it was eye candy. So I doubt that a branch would help.
There exist a couple of troublesome elements in basic classes. IMO the Controls unit with those many managers deserves downstripping and refactoring, for better maintenance and extensibility. It should be reconstructed bottom-up, with defined hooks for features and implementations to-be-added.
It has been done the other way round. Where huge experimental changes have been done in a branch and later merged. For example the "lcl smartlink" branch.
That's okay with modifications of almost known impact, which are implemented by a single person. Refactoring with an impact on many places cannot be done this way.
You're right, a branch for itself won't help. What I want is an extract of the existing code, from which in the first step everything is excluded that is not documented in Delphi or somewhere else, and that is not fully implemented and tested. The excluded functionality is replaced by hooks that allow to add according code later, with little impact on the remaining code. When the design is okay, it should be extensible by simply adding modules to the core implementation.
I am sure if there was a request, and someone behind it to do the work, and if the concept of the changes was *agreed* on, then a branch could be created, and later merged back (just my opinion).
Merging back should not really be required in a modular approach. It's the required redesign of the base classes, that is usually blocked by "it works as is, why change it?", and by the consequential work required in other places of the existing code base :-(
As for getting the essentials done. the problem is to find a volunteer. The "developers" are volunteers too, they do what they volunteered for. Not what some one else would want them to do (well actually plenty of times they do, what others want).
It's not a matter of *what* somebody wants to do, but IMO a matter of *how* it should be done, if ever. Bloating the code base should be allowed *only* with according documentation, everything else should be kept out of the trunk. But actually the privileged project members work on what they like to do, leave critical pieces "for later" - meaning "somebody else shall do it" - and then continue with something else. Many contributions are blocked this way, when they deserve hooks that do not already exist in the code base.
IMO we should have an independent project management, establishing the goals (and priorities) for a usable product, and kind of quality control, that is entitled to request documentation and verification from the implementors. All contributors should be proud of having their contributions acknowledeged and added to the project, not only of "I added something that looks useful or nice".
DoDi -- _______________________________________________ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
