[Lazarus] debugger feature request created

[Martin]

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