I noted a syntax problem (maybe?) in usage of generics.
...
In other cases, when I put the unit name before the type it is ok.
It's not a bug
It's not a bug, you are just using the wrong syntax:
var lst : fgl.specialize TFPGList<Integer>; begin lst := fgl.specialize TFPGList<Integer>.Create; end.
I would consider this a bug...
So what with this specialize keyword?Does the documentation (https://lazarus-ccr.sourceforge.io/fpcdoc/ref/refse51.html) answer your question?
So what with this specialize keyword?Does the documentation (https://lazarus-ccr.sourceforge.io/fpcdoc/ref/refse51.html) answer your question?
So what with this...
So what with this specialize keyword?Does the documentation (https://lazarus-ccr.sourceforge.io/fpcdoc/ref/refse51.html) answer your question?QuoteSo what with this...
Translation:
So what the :o :o :o is up with this... O:-)
I don't quite understand what it is. Was my final question understood as a so-called "litigiousness" or "nitpicking"? If so, there was a misunderstanding.
So what with this specialize keyword?Does the documentation (https://lazarus-ccr.sourceforge.io/fpcdoc/ref/refse51.html) answer your question?
Is there an alternative notation that would be more "pascalish"? For example like this:
var lst : specialize fgl.TFPGList<Integer>; begin lst := specialize fgl.TFPGList<Integer>.Create; end.
The first way, where the keyword specialize is "mixed in" into part of the name, is not very readable. Delphi mode does not use this keyword.
So was it really necessary to add this keyword? Perhaps the rule of "don't multiply entities beyond necessity" should have worked here (i.e. if the syntax of the language is readable without additional syntax elements, then you probably shouldn't add them).
However, if there are any reasons to use this word, then perhaps it should appear before the type name? After all, the fgl prefix only specifies the name of the module from which this class comes (it becomes part of the type name).
So what with this specialize keyword?
And all of you should learn to specialize as a type not on a var.
That is plain stupid, although it is allowed.
This is a rather bizarre notation:
var lst : fgl.specialize TFPGList<Integer>; begin lst := fgl.specialize TFPGList<Integer>.Create; end.
Is there an alternative notation that would be more "pascalish"? For example like this:
var lst : specialize fgl.TFPGList<Integer>; begin lst := specialize fgl.TFPGList<Integer>.Create; end.
The first way, where the keyword specialize is "mixed in" into part of the name, is not very readable.
Delphi mode does not use this keyword. So was it really necessary to add this keyword? Perhaps the rule of "don't multiply entities beyond necessity" should have worked here (i.e. if the syntax of the language is readable without additional syntax elements, then you probably shouldn't add them).
However, if there are any reasons to use this word, then perhaps it should appear before the type name? After all, the fgl prefix only specifies the name of the module from which this class comes (it becomes part of the type name).
or just drop fgl. .. not the library, but the prefix
var lst : specialize TFPGList<Integer>;
even better, declare a type first. Keeps your code cleaner.
{$mode objfpc} uses fgl; type Tlst = specialize TFPGList<Integer>; var lst : Tlst; begin lst := Tlst.Create; Lst.Free; end.
The unit prefix only makes sense if you combine multiple generics libraries, like fgl, lgenerics and or rtl-generics and all of that also in the same unit....
You are not thinking far ahead enough: the problem is if you have multiple specialization in one statement. E.g. SomeUnit.specialize SomeTypeA<TypeX>.specialize SomeTypeB<TypeY>.specialize SomeClassFunc<TypeZ>. By having the specialize be part of the identifier to be specialized things are much clearer.There could be other solutions, e.g. . could have precedence over specialize, so it would be:
Also this simply won't work in FPC < 3.3.1 due to it not handling unit names together with generics correctly (it will pick the generic from one of the two units, not necessarily the one you specified, assuming it's indeed available in multiple units).Well, it does in 3.2.0 because fgl.TFPGList<> and generics.collections.Tlist<> are resolved correctly?
Also this simply won't work in FPC < 3.3.1 due to it not handling unit names together with generics correctly (it will pick the generic from one of the two units, not necessarily the one you specified, assuming it's indeed available in multiple units).Well, it does in 3.2.0 because fgl.TFPGList<> and generics.collections.Tlist<> are resolved correctly?
If not, I stand corrected, again... But that is in the context of my example not the the case because the roots differ in name.
Or, as usual, am I missing something?