<p>Am 29.01.2016 08:03 schrieb "taazz" <<a href="mailto:taz@evosi.eu">taz@evosi.eu</a>>:<br>
><br>
> On 28/01/2016 12:20 μμ, Sven Barth wrote:<br>
><br>
>> Am 28.01.2016 08:06 schrieb "taazz" <<a href="mailto:taz@evosi.eu">taz@evosi.eu</a> <mailto:<a href="mailto:taz@evosi.eu">taz@evosi.eu</a>>>:<br>
>>  > 1) if dots do not allow me to do something along the lines of<br>
>>  >   Uses<br>
>>  >     Core.Text;<br>
>>  >   Instead of<br>
>>  >   Uses<br>
>>  >     Core.Text, Core.TExt.XML, core.Text.Json;<br>
>>  >   Then I would prefer to avoid having to type the dots and stick to<br>
>> the camel case unit names only, same effect in my book.<br>
>><br>
>> Dotted unit names allow you to omit prefixes if they have been passed on<br>
>> the commandline (Delphi allows this, FPC not yet however). E.g. you'd be<br>
>> able to write "uses Text, Text.Xml, Text.Json" if "Core" is passed on<br>
>> the commandline as namespace to search in.<br>
><br>
><br>
> 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.</p>
<p>Lazarus usually picks up new commandline parameters rather fast. Especially ones like these.</p>
<p>><br>
>> The problem is when we introduce a new unit with a logical, fitting name<br>
>> that then conflicts with a unit a user already had.<br>
>> And why should we clean up the fpXXX function? I don't get what you're<br>
>> hinting at.<br>
><br>
><br>
> 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.<br>
><br>
> 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.</p>
<p>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.</p>
<p>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.</p>
<p>><br>
><br>
><br>
>>  > 3) Are you really going to introduce a 3rd (if memory serves me<br>
>> right) generics lib in the mix? Clean up guys the rtl must not have any<br>
>> duplicates it must have one and only one implementation, extra libraries<br>
>> can always be shared and if required installed by the user but not<br>
>> installed by default my disk space is not your playground.<br>
>><br>
>> This third generics library is a Delphi compatible one so that's a big<br>
>> plus. The others must stay for backwards compatibility (also fgl is a<br>
>> nice test durog cycling the compiler that nothing basic was broken with<br>
>> generics; one of the main reason it's still in rtl and not rtl-objpas or<br>
>> rtl-extra).<br>
>><br>
><br>
> 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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Regards,<br>
Sven</p>