How to keep track/organize all overloaded, extended 3rd party source code?

[Mike Torrettinni 199]

As probably many of you, I have some extended or modified/patched 3rd party source code, or RTL. And it differs from project to project, depending on the needs.

So, when component is updated I compile project by project to see what needs to be 'patched' or if developers of those components implemented the same features, as my code 'adds/fixes'.

 

I was thinking to copy all extended and overloaded sources, from all projects, to single new project and just compile this project every time I update any of the 3rd party source. Is there better approach?

I would like to have a 1 common approach/action to this, so when I update one (or any) of the components, I can verify all the changes that are needed for all the projects, with 1 action.

 

The fact that I have extended, overloaded different parts of the same component for different projects, whatever is needed in that project - is this wrong approach?

 

How do you deal with this?

[Lars Fosdal 1866]

If I can avoid it, and I usually can, I do not modify third party code. It adds to the maintenance burden. 

[FPiette 393]

I don't usually modify 3rd party source code. Sometimes, I inherit from the 3rd party, adding my code only in separate source. If what I need cannot be done with inheritance en encapsulation, if I still find the 3rd party code valuable, I contact the author asking him to make some methods virtual or expose new properties. If he doesn't want, then I don not use his code because - as you experience - it will be a lot of work in the future.

 

[Mike Torrettinni 199]

I'm not used to contacting component developers, except in rare occasions when there is 'interest' on the other side to get to know how I use their source, or some other reason for a contact. Otherwise you get generic response 'will look into it',

And it's annoying when they don't want to implement something I suggest 🙂 so I don't bother. But I never considered not using the component, if they don't want to implement something just for me.

[FPiette 393]

2 hours ago, Mike Torrettinni said:

And it's annoying when they don't want to implement something I suggest 🙂 so I don't bother.

 

I'm a long time developer of open source components and I know this problem very well.

 

The idea is not to ask the component developer to implement something you'd like but ask very simple thing like making a method virtual or change a method visibility from private to protected. Then you'll be able to implement yourself what you need in a derived class. Asking for such simple things which present almost no risk to break something is likely to succeed. But asking the component developer to implement something for you will probably be rejected. You'd better chances to implement it yourself and suggest your changes.

 

[Arnaud Bouchez 411]

Try to push a pull request to the original project, if it is Open Source.
If it is useful to you, it may be useful to others.
The pull request may not be directly merged, since the project owners may have some requirements (testing, code format, comments, documentation, cross-platform...).

It is a great way to enhance your abilities, and give back to the community.

 

For 3rd party non-free components, it is more difficult.
You may use the branch feature of a SCM (git or fossil e.g.) to backport the original 3rd pary code updates to your patched branch.

Edited August 9, 2020 by Arnaud Bouchez

[David Heffernan 2455]

It's possible that the changes you are making to the third party code should be made in your code instead, thus side stepping the problem. 

[Guest]

I have, last decade, moved to 3rd party vendors that *listen* to my needs.

I used to have projects with modified code, it becomes a mess. Not the first year maybe, but then...

I am having two beefs with DX and one with nn.

I cannot swap out DX but if nn keep displaying blatant uninterest, i'll swap it out*. Not that that will be easy nor cheap.

So my $.05; don't patch, just don't. You should always have the code, for debugging and understanding - not for changing.

 

Another thing is that considering at least VCL and UI, there's a lot of things that can be handled by assigning your own code to VCL globals and a host of other tricks... so first, as David points out above, make it 100% clear that the problem cannot be handled in another way.

 

Another great way of putting some pressure on commercial 3rd party vendors is to set up a successful opensource project that depends on their library with the deficiency pointed out in *bold*. In that situation you'll have peers that can agree with you that the requested change is needed and sound.

 

* Pls note, i am not the only user with that exact same request. Also note, "nn", is not the real name of the vendor. Still hoping for that "virtual" to be inserted in the right place.

[Mike Torrettinni 199]

Well, no matter how I extend, patch the source code, I need to verify if all works as it should on every source update. I only 'trust' Delphi's source to be backwards compatible, so no need to check if extended controls work.

But, if I need (or want) something changed, I see no reason not to. The benefit of customization outweighs the maintenance.

 

You can't always extend some things, right? Records are one of them... for example: I used to have xml library that had XMLNode.GetAttributeAsInteger, the new (better) xml library doesn't. So, since .ToInteger fails on empty strings, and I prefer using StrToIntDef as little as possible, I just added the new method to the library source. When I update the xml library it will fail on compile of the project that uses new method and I will copy/merge missing method to new source.

 

Or Virtualtreeview - for years I had my own AutoFitColumnWidthIncludingCaption, which was implemented I think in one of the latest updates (this or last year) -so I guess I will not need this patch anymore.

 

I think a blank project, probably named 3rdPartySourceCodeMiantenance, that will reference all changes to all changed sources should be good solution. And every time I update any of the libraries, I will compile this project first and patch as needed - of course verify that the patches are needed.

 

Perhaps I need to rethink my approach to the component developers, perhaps I should be more involved.

[David Heffernan 2455]

3 hours ago, Mike Torrettinni said:

You can't always extend some things, right? Records are one of them... for example: I used to have xml library that had XMLNode.GetAttributeAsInteger, the new (better) xml library doesn't. So, since .ToInteger fails on empty strings, and I prefer using StrToIntDef as little as possible, I just added the new method to the library source.

This is what class helpers are for. 

 

3 hours ago, Mike Torrettinni said:

Or Virtualtreeview - for years I had my own AutoFitColumnWidthIncludingCaption, which was implemented I think in one of the latest updates (this or last year) -so I guess I will not need this patch anymore.

Likewise. 

[Mike Torrettinni 199]

14 minutes ago, David Heffernan said:

This is what class helpers are for. 

Thanks. Whenever I think about these I remember 'you can only have 1 active record helper at a time...' and I stop as I have no idea if that means it will stop other helpers working.

[Fr0sT.Brutal 904]

IMHO:

1. Think if a feature could be useful for others, if yes - suggest it to developer

2. Try to implement it by inheriting, class helpers, class hacks etc

3. If nothing helps, go the way of source modifying. But prepare to handle all updates manually. Luckily most of this work could be done with source control systems.

 

I keep several personally needed changes to ISC, VTV, FastReport but where possible I use class helpers (VTV) or inheritance (ICS). Sometimes the following trick helps a lot:

type
  class TSomeStdClassExt = class(TSomeStdClass)
  ... // some additional stuff
  end;

  class TSomeStdClass = TSomeStdClassExt;

var someobj: TSomeStdClass; // will be of class TSomeStdClassExt actually

It is especially useful for visual controls b/c you don't have to register new control, replace old ones with new ones and so on.

Edited August 9, 2020 by Fr0sT.Brutal

[Mike Torrettinni 199]

6 minutes ago, Fr0sT.Brutal said:

class helpers,

Aha, I keep mixing class and record helpers. I know how to extend class, not the record. Same for replying to David's comment, I thought he was referring to record helpers.

[David Heffernan 2455]

10 minutes ago, Mike Torrettinni said:

I thought he was referring to record helpers.

I literally wrote class helpers. 

 

2 hours ago, Mike Torrettinni said:

Whenever I think about these I remember 'you can only have 1 active record helper at a time...' and I stop as I have no idea if that means it will stop other helpers working.

It will. That's a problem if you are using other helpers for the class. Are you? 

[Mike Torrettinni 199]

 

15 minutes ago, David Heffernan said:

It will. That's a problem if you are using other helpers for the class. Are you? 

No, no class helpers of my own.