The right implementation of generics

[hnb]

Yes I know! Thanks for all explanations!

side note: rtl-generics has also many implementations of TDictionary (Delphi has only one: open addressing with linear probing). More details about associative arrays (we have very good benchmark prepared by Benito to show all important characteristics):

http://www.benibela.de/fpc-map-benchmark_en.html

related topic:

http://forum.lazarus.freepascal.org/index.php/topic,34348.msg226229.html

good luck

[simone]

I have migrated my project to RTL-Generics. I got the confirmation that this implementation of generics is very nice and better than FGL. The task has been simple, since I used only TFPGObjectList, that I mapped to TObjectList. After this modification, my application pass all regression tests without problem. The strange (very strange) thing is that also in this situation, I have internal errors when I do some changes in data structure, for example if I modify a field in the public section of a class...

[PascalDragon]

Most important to help you here would be bug reports that contain the internal error that happened and as simple examples as possible.
Since you said that this usually happens upon recompilation it should usually work with three or four units that reference each other. So look for that and try to comment out code to simplify things.

[simone]

I'm working to reduce the amount of code (about 10kloc in 20 units)  to a minimal subset that makes reproducible all the internal errors with different id codes. A the end of  this process, I will submit a bug report. This task is not simple for me, for lack of specific experience...

[Akira1364]

Honestly the only real problem with generics and FPC/Lazarus isn't internal errors in my opinion, it's the fact that the internal Lazarus "CodeTools" parser is utterly incapable of dealing with them properly (as in "identifier expected near specialize" and such, ad nauseum), and that for some reason no one seems to think it's worth fixing. (Even though it's a blatant, glaring, constant issue!) FPC itself handles and compiles generics just fine, for the most part.

[jc99]

@Akira1364: +1
CodeTools, Cody and even the beautifier should be able to handle all of the language that is bundled with the release.
(rtl-generics might be an exception yet, since it is not released yet)

[Edit]
One more thing:
In this stage it's ok to point to an embarcadero-documentation, but at the time rtl-generics become part of the release there should be
a documentation of our own. So how about starting a series of Wiki-pages that can emerge into a full documentation someday.

[Akira1364]

@Akira1364: +1
CodeTools, Cody and even the beautifier should be able to handle all of the language that is bundled with the release.
(rtl-generics might be an exception yet, since it is not released yet)

Uh, no. It's certainly not even remotely close to being able to handle everything it should be able to. "Expression must be class or record type" over and over and over again, and such. No, it "musn't", you are just an outdated parser, Mr. CodeTools! This is mostly when working with {$mode objFPC} generics, I should note. I would honestly vastly prefer to use Delphi-style Generics syntax (as I think 99% of developers would), but much to my annoyance I can't do that without using full-on {$mode Delphi} which has far too many downsides to be worth it. I'm unsure why Generics syntax specifically is so strictly tied to the full language "modes", when everything else in FPC can be enabled or disabled with a {$modeswitch} directive. There is no logical reason why I shouldn't be able to use Delphi-style generics in an otherwise {$mode objfpc} project. The only reason I can't is because of an entirely arbitrary limitation (that should not exist in the first place) set by some member of the FPC/Lazarus dev team. 

Also, I have no idea what you mean when you say RTL-Generics "isn't released yet."

[Thaddy]

Also, I have no idea what you mean when you say RTL-Generics "isn't released yet."

It isn't in an official release. It is in trunk. It needs compiler features from trunk.

[jc99]

@Thaddy: That's what I meant, it's not in the (official) release! (@A:)What is miss-understandable about that ?
And I am not talking about now. I talk about the time (in the future) when It's part of the (official) release. Then it would be a bad user-experience when reformatting your code, adding a with and so on offered by the IDE gives you a cryptic error-message even if there is no mistake at all, only because the tool (which is part of the (official) release) can't handle the code right.

So my suggestion was, to start now, ...

It needs compiler features from trunk.

I think that's not true anymore, I could compile the trunk-rtl-generics with FPC 3.0.2 without a hassle. I even made a package to include the rtl-generics to projects where it's needed.
see: http://forum.lazarus.freepascal.org/index.php/topic,34040.msg246348.html#msg246348

@Akira1364: Do you say you want the Omelet but don't want to break the eggs ? You want delphi-style-this and don't want delphi-style-that so what do you really want ?

[JuhaManninen]

Nobody is against having a solid generics support in CodeTools. Now it is partly missing and broken.
As always in FOSS, somebody just has to implement it.
Contributions are welcome.

[PascalDragon]

@Akira1364: +1
CodeTools, Cody and even the beautifier should be able to handle all of the language that is bundled with the release.
(rtl-generics might be an exception yet, since it is not released yet)

Uh, no. It's certainly not even remotely close to being able to handle everything it should be able to. "Expression must be class or record type" over and over and over again, and such. No, it "musn't", you are just an outdated parser, Mr. CodeTools! This is mostly when working with {$mode objFPC} generics, I should note. I would honestly vastly prefer to use Delphi-style Generics syntax (as I think 99% of developers would), but much to my annoyance I can't do that without using full-on {$mode Delphi} which has far too many downsides to be worth it. I'm unsure why Generics syntax specifically is so strictly tied to the full language "modes", when everything else in FPC can be enabled or disabled with a {$modeswitch} directive. There is no logical reason why I shouldn't be able to use Delphi-style generics in an otherwise {$mode objfpc} project. The only reason I can't is because of an entirely arbitrary limitation (that should not exist in the first place) set by some member of the FPC/Lazarus dev team.

This is primarily due to historic reasons: Generic support had been added to FPC before Delphi had it and since it wasn't Delphi compatible anyway it was added only to the non-Delphi modes.
I do plan to make this changeable by a modeswitch, but before that I want to reduce a few more differences between the two modes (e.g. that one isn't allowed to overload a generic type with another generic type of the same name which is supported in mode Delphi, but not in the FPC modes [it does work for generic routines however]) without sacrificing backwards compatibility.

Please note that currently the generics in Delphi mode have the restriction that complex inline specializations aren't yet possible (e.g. "SomeFunc<LongInt>(42) + SomeFunc<Longint>(21)").

[Thaddy]

I do plan to make this changeable by a modeswitch, but before that I want to reduce a few more differences between the two modes (e.g. that one isn't

What?... It IS changable by a mode switch... Who's talking?

[PascalDragon]

I do plan to make this changeable by a modeswitch, but before that I want to reduce a few more differences between the two modes (e.g. that one isn't

What?... It IS changable by a mode switch... Who's talking?

Modeswitch, not mode, that's a difference. You currently can't have mode ObjFPC with Delphi's generic syntax or the other way round as there's no separate modeswitch for that. I should know, cause I'm rooting around in the compiler more often than not. 

[jc99]

I hope that you are successful with that. It would be a great PLUS !!

[Thaddy]

Modeswitch, not mode,

I wrote Mode switch, not modeswitch. It is a switch that changes modes, not modeswitches.