[Lazarus] debugger feature request created

[Hans-Peter Diettrich]

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