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

Sven Barth pascaldragon at googlemail.com
Thu Jan 28 11:20:49 CET 2016

Am 28.01.2016 08:06 schrieb "taazz" <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.

> 2) As the main distribution of fpc, you have the obligation to keep rtl
and other libraries clean from any prefixes, the user's obligation is to
make sure that his unit names to not conflict with the rtl not the other
way around and since we are on the same subject clean up the fpXXX
functions as well it breaks conformity.

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.

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20160128/31d36760/attachment.html>

More information about the fpc-devel mailing list