[fpc-devel] Generics.Collections as package for Lazarus or package for FPC RTL

[Sven Barth]

Am 29.01.2016 08:03 schrieb "taazz" <taz at evosi.eu>:
>
> On 28/01/2016 12:20 μμ, Sven Barth wrote:
>
>> Am 28.01.2016 08:06 schrieb "taazz" <taz at evosi.eu <mailto:taz at evosi.eu>>:
>>  > 1) if dots do not allow me to do something along the lines of
>>  >   Uses
>>  >     Core.Text;
>>  >   Instead of
>>  >   Uses
>>  >     Core.Text, Core.TExt.XML, core.Text.Json;
>>  >   Then I would prefer to avoid having to type the dots and stick to
>> the camel case unit names only, same effect in my book.
>>
>> Dotted unit names allow you to omit prefixes if they have been passed on
>> the commandline (Delphi allows this, FPC not yet however). E.g. you'd be
>> able to write "uses Text, Text.Xml, Text.Json" if "Core" is passed on
>> the commandline as namespace to search in.
>
>
> Although I see the benefit of this I do not see me using it. my goal is
to avoid the command line and minimize typing as much as possible with out
loosing functionality.

Lazarus usually picks up new commandline parameters rather fast. Especially
ones like these.

>
>> The problem is when we introduce a new unit with a logical, fitting name
>> that then conflicts with a unit a user already had.
>> And why should we clean up the fpXXX function? I don't get what you're
>> hinting at.
>
>
> That is not the fpc team's responsibility. Keep it clean, keep it simple,
keep it easy to learn. Any external library will have to do what ever it
can to avoid those kind of problems in most cases the easiest way is to
prefix the units with a company/author 3 or 4 letter prefix or in the case
of dotted unit names a complete namespace.
>
> As for the FPxxxx functions, same clean up group, no prefix for the main
distribution. Not in the unit names and especially not for the function
names. That is something the 3rd party library developers do and they do
not need any competition from fpc.

The FP prefixes for the generic types were introduced, because the compiler
could not handle cross unit type overloads with generics correctly. Now
they are part of backwards compatibility.

The fp prefixes for the Posix functions are there to avoid confusion with
the native Pascal functionality (e.g. mkdir) and for consistency all these
functions have the prefix.

>
>
>
>>  > 3) Are you really going to introduce a 3rd (if memory serves me
>> right) generics lib in the mix? Clean up guys the rtl must not have any
>> duplicates it must have one and only one implementation, extra libraries
>> can always be shared and if required installed by the user but not
>> installed by default my disk space is not your playground.
>>
>> This third generics library is a Delphi compatible one so that's a big
>> plus. The others must stay for backwards compatibility (also fgl is a
>> nice test durog cycling the compiler that nothing basic was broken with
>> generics; one of the main reason it's still in rtl and not rtl-objpas or
>> rtl-extra).
>>
>
> Keep the new, drop the old or merge. if fgl is good for the compiler then
keep it as a unit testing and share it for existing users. I do not think
that it needs to be part of the main installation. The fgl user base, I
believe, already knows how to download and install external dependencies.
At least make it an opt in/out in the installer while the new is part of
the required packages and fgl is not auto installed.

We go to great lengths to preserve backwards compatibility. So we won't
simply drop a unit just because the one or other user can't handle more
than one generic container library. Also the three libraries have different
use cases. The one from Maciej is Delphi compatible and fast, but on the
other hand comparatively heavy weight. The fcl-stl is more like the C++ STL
in it's usage and more lightweight (also it supports functionality that fgl
does not, like the TDeque). Fgl then is just a simple implementation of the
containers. Just as lightweight, but slower and less feature rich than
Generics.Collections.

Also you don't seem to have a clue how the building of the compiler works.
I want to know of a breakage of the generics as soon as possible and that's
only possible if the unit is part of the core RTL. Otherwise I could simply
run the testsuite, which covers far more tests. But if I can't compile fgl
already, why should I do a rebuild of all packages and a run of the
testsuite... That's just a waste of time that I better spend fixing the bug.

TL;DR: The three libraries will stay as they are. Maybe fcl-stl will be
moved to the fppkg based repository in the long term, but that's it.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20160129/727d89e7/attachment.html>