[fpc-devel] Generics.Collections as package for Lazarus or package for FPC RTL
taz at evosi.eu
Thu Jan 28 16:36:26 CET 2016
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.
> 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.
> > 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
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.
As always only observations and my own "successful" practices.
Your tool your choice.
Keep in mind that I already have around 20 classes based on fgl unit, so
if the changes above are to happen it will take me around a week
changing the code to the new generics and retesting everything. If I had
more than that I would probably expect some sort of
More information about the fpc-devel