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

[stdreamer]

On 29/01/2016 11:54 πμ, Sven Barth wrote:
> Am 29.01.2016 08:03 schrieb "taazz" <taz at evosi.eu <mailto: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> <mailto: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.

That's your prerogative, its a waste of time but its your time.

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.

Sure go ahead.

>
> Also you don't seem to have a clue how the building of the compiler
> works.

No I don't and thankfully I don't need to learn.

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.

I disagree but its not interesting enough to spend more time.

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

Yeah because rebuilding all the packages and running the complete suit 
is the only possible way to work.

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

Sure, your time go ahead have fun.