On 29/01/2016 11:54 πμ, Sven Barth wrote:
Am 29.01.2016 08:03 schrieb "taazz" <[email protected] <mailto:[email protected]>>:
>
> On 28/01/2016 12:20 μμ, Sven Barth wrote:
>
>> Am 28.01.2016 08:06 schrieb "taazz" <[email protected]
<mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>>:
>> > 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.
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
