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

[taazz]

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
> 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.


As always only observations and my own "successful" practices.
Your tool your choice.

PS
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