I can only very limited answer the below, since without knowing the
exact changes in mind I can not judge what is or what is not (according
to my opinion) possible
I know there was discussion, do you have the link to it in the archives?
Hans-Peter Diettrich wrote:
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.
To be honest your description does sound more like a rewrite from
scratch (copying bits and pieces in), than just a refactor....
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.
Can the functionality not be moved in small steps?
I usually found often in situations like this that it can. It may take a
bit longer to do, and it may need some temporary compromises, where the
old code keeps some direct links to the new code, whcih will be removed
at a later stage....
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 :-(
Then maybe a branch may not even be needed. A branch usually means
things get merged at some time. (imho)
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.
What and how translate to the same in this case. Creating a structure
like you describe (the "how") is work that needs to be done. And work is
"what". If no-one sits done to to the work then it isn't done.
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".
Well the style a project is done, is defined by those who created it. If
you can convince them.....
On the other hand the project has come very far, with how it's been done
until now.
Anyway as I said if you had the link to the original discussion?
Martin
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
