Blogged : Advice for Delphi library authors

[Uwe Raabe 2057]

2 hours ago, mvanrijnen said:

Where is this documented, i search a couple of times where these things are documented but could not find anything at embarcadero.

 

http://docwiki.embarcadero.com/RADStudio/Sydney/en/10.4_Sydney_-_Release_1#Projects

[Bill Meyer 337]

9 hours ago, Fr0sT.Brutal said:

Doesn't upgrade from GetIt solve this issue?

GetIt doesn't -- in most cases -- let you put things where you would  like.

[Remy Lebeau 1393]

14 hours ago, Vincent Parrett said:

LIBSUFFIX doesn't affect the dcp file names, only the bpl. 

I know.  But since Indy has never used LIBSUFFIX, its package project names are suffixed, and so the dcp files are also suffixed.

14 hours ago, Vincent Parrett said:

I have to say that I wish Embarcadero were not shipping Indy so intertwined with the product.

Well, they do use Indy inside some of their own tech, so they need a stable version to link against.  But they are supposed to be using a private copy that is separate from the public copy they ship for users.

 

That being said, it is a goal for Indy to eventually be phased out of the IDE releases and move into GetIt instead.  But its complicated installation steps (more for C++ than Delphi) makes that difficult right now.  I'm hoping to clean that up in Indy 11.

14 hours ago, Vincent Parrett said:

Pretty much the first thing I do when installing Delphi is remove all traces of Indy so that I can install my own version (usually later than the one they ship).  

True, most IDE releases don't ship with the latest Indy release available at the time.  10.4 did, though (which its Indy is already not the latest anymore).

[Remy Lebeau 1393]

11 hours ago, dummzeuch said:

I offered to help out and even submitted pull requests with updates for them, but they were ignored for several months. Then I gave up.

I just looked at the Pull Request history, and I do see 2 requests that you had submitted and then closed.  I don't think I ever saw them while they were open, otherwise I would have merged them.  I have merged them now, and I will look into whether your changes should to be merged into other scripts.

Edited February 25, 2021 by Remy Lebeau

[Uwe Raabe 2057]

18 hours ago, Remy Lebeau said:

But the package names having hard-coded suffixes is not about being sloppy, it is about backwards compatibility. 

That may be true for the Delphi 4 and 5 packages, but can easily be dropped for all others. The naming of the bpl files would still be the same.

Quote

it was too late to update Indy 10 without major breakages in existing user code

Honestly? With the current scheme you have this breakage for each new Delphi version.

[Remy Lebeau 1393]

4 hours ago, Uwe Raabe said:

That may be true for the Delphi 4 and 5 packages, but can easily be dropped for all others. The naming of the bpl files would still be the same.

But the naming of the DCP would change, and that would break existing projects.  At the very least, I would have to issue an advisory and document that any Indy upgrades made past X release would require project updates to continue using Indy.  I was waiting until Indy 11 to make that change, since I'm restructuring the packages anyway.

Edited February 26, 2021 by Remy Lebeau

[Stefan Glienke 2002]

8 hours ago, Remy Lebeau said:

waiting until Indy 11

I wonder when that will happen given the oldest mention of that version I remember was in 2010

[Uwe Raabe 2057]

10 hours ago, Remy Lebeau said:

At the very least, I would have to issue an advisory and document that any Indy upgrades made past X release would require project updates to continue using Indy.

As I said, a customer now has to tweak the requires clause of his package using Indy for each new Delphi version anyway. If you start the new scheme for the 10.5 packages and keep the old as is, you don't have any compatibility issue at all. At least this will ease the use of Indy in all versions 10.5 up.

 

A backport to packages for older Delphi versions can then be done separately if feasible.

 

The interesting thing is that the Indy version delivered with Delphi already follows the LIBSUFFIX approach.

package IndyIPClient;
...
requires
  rtl,
  IndyCore,
  IndyProtocols,
  IndySystem,
  CustomIPTransport,
  IndyIPCommon;

That said, using the non-included Indy packages already lays a burden on the user, because the requires clauses won't match when switching to a non-included Indy version.

 

Even more: the necessary package changes are already available and ready for use.

[Remy Lebeau 1393]

5 hours ago, Stefan Glienke said:

I wonder when that will happen given the oldest mention of that version I remember was in 2010

My plan for Indy 11 many years ago was very different than the current plan.  Originally, Indy 11 was going to be for a bunch of new features I was working on.  Then a few years ago, we decided to make Indy 11 be just a maintenance release instead to cleanup the existing codebase (drop old compilers, cleanup ifdefs, etc), and push back new features to Indy 12.  The "Restructure" branch currently in the GitHub repo is what will eventually become Indy 11.  The majority of the work is already done, it just needs to be brought up-to-date with the latest master branch, rebranded, validate everything builds with the new folder/naming structures, etc.

[John Kouraklis 94]

On 2/25/2021 at 9:56 AM, timfrost said:

In the Webinar yesterday, responding to a question about compiler updates/upgrades, I heard Marco say that 'Getit is a bit of a problem because it always uninstalls the old version before installing'. How can anyone defend this approach? What happens when you test the new version and something fails to work?  Where is the old source code for you to compare the differences and either fix them or adjust your usage?  A component installer should never force an install into the location of the production library; it should always be checked and validated before it is too late to do this.

Sometimes I am speechless when I hear the way some people in EMBA respond to questions. They have a degree of naivety that makes you think they are talking about a product from another company😏  

[Vincent Parrett 750]

7 hours ago, Remy Lebeau said:

Then a few years ago, we decided to make Indy 11 be just a maintenance release instead to cleanup the existing codebase (drop old compilers, cleanup ifdefs, etc), and push back new features to Indy 12.

I like this plan. I ran FixInsight over the code and there are lots of opportunities to clean up the code. Unfortunately fixinsight also produces a lot of 'noise' because there are lots of empty virtual methods which appear to be for c++builder support (no abstract support in c++ builder?) - but it's still a worthwhile exercise.  

 

I look forward to the day I can install Delphi, chose not to install the bundled Indy and install Indy via DPM, choosing which particular version I want, and not having to modify my projects as Libsuffix will be set on the packages 😉

 

[John Kouraklis 94]

3 hours ago, Vincent Parrett said:

I like this plan. I ran FixInsight over the code and there are lots of opportunities to clean up the code. Unfortunately fixinsight also produces a lot of 'noise' because there are lots of empty virtual methods which appear to be for c++builder support (no abstract support in c++ builder?) - but it's still a worthwhile exercise.  

 

I look forward to the day I can install Delphi, chose not to install the bundled Indy and install Indy via DPM, choosing which particular version I want, and not having to modify my projects as Libsuffix will be set on the packages 😉

 

Pascal Analyser is more thorough I think

[Vincent Parrett 750]

7 minutes ago, John Kouraklis said:

Pascal Analyser is more thorough I think

It suffers the same issues as FixInsight.. a lot of noise produced too. Bothe FixInsight and Pascal Analyser both do a good job of finding simple things and enforcing best practice but they don't do flow analysis.  

 

https://blog.sonarsource.com/kill-the-noise-to-change-gear-in-our-code-analyzers

 

Something like SonarQube would be good, there is a delphi plugin, this appears to be the most up to date fork - https://github.com/JAM-Software/SonarDelphi - it doesn't do flow analysis either (like the built in language support in sonarqube does for C# etc). Note I haven't tried it (yet), just peeked at the source code.

 

[Remy Lebeau 1393]

10 hours ago, Vincent Parrett said:

there are lots of empty virtual methods which appear to be for c++builder support (no abstract support in c++ builder?)

C++ supports abstract classes. But abstract classes in C++ can't be used in all contexts that Delphi supports them. Also, not all of the empty methods are for abstract support, they are simply placeholders to allow descendants to hook into strategic places if they want to.