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

[Anthony Walter]

Tomas,

> Alright. So what is the authorship of the default units and how does it
> fit to Delphi compatibility?

At some point (soon) I hope Free Pascal and Lazarus will expand beyond
being Delphi compatible. In my recommendations I did not mean to infer that
Delphi compatibility should be broken or removed, but that new units or
even a new library can be added to Free Pascal or Lazarus which could be
considered a new "Core" set of Pascal libraries. This "Core" library would
offer a much improved Pascal coding experience with extensions to intrinsic
types like string or array or integer.

I posted on these lists previously about my very quick string library, both
in terms of execution speed and also in ease of use. The string type helper
extensions I've written make tasks like parse test or html relatively ease
with functions like FirstOf, SecondOf, LastOf, BeginsWith, EndsWith,
Contains, Split, Join, and so on. I also make good use of implicit
conversions in both my Array<T> and ArrayList<T> types as well as in the
Networking area.

So to answer that question, my proposal would not impact migrating from
Delphi to Lazarus, nor would it prevent you from using theses Core
libraries in Delphi (as long as the languages are the same).

> Nobody prevents vendors to use their namespace now, right?

Dotted namespaces weren't supported officially by FPC until two months ago
with the release of FPC 3.0. And it wasn't until recently that most of the
code tools and documentation issues with dotted namespace units were fixed.
I sent a patch just this month to fix allow for dotted names in the
documentation tool chain. Now that we're a few months past that point I
think we should look towards integrating them, and that is why I am raising
this subject now and not one year ago.

> The reason of current distribution is primarily due to multiple sources.
> See http://wiki.freepascal.org/Unit_categorization (now certainly
> incomplete, but still showing the point). Certain functionality gets to
> the FPC codebase due to compatibility with Delphi, etc., other stuff is
> added by us due to missing functionality (which may get added under a
> different name and to a different unit in Delphi later), etc. Lazarus
> decides on what to add where independently based on their needs. And so
> on. How could namespaces solve that?

You're kind of making my point, and that is some units and the functions in
them are reserved for Delphi compatibility. Great, we can have Delphi
compatibility, but for added on specific functionality it should probably
be noted as such "Core.Text". And this makes it very plain, if the code is
going to be original to and to be maintained by the Free Pascal team
members, then "Core.Text" is where all string related functions would go.
If you need something a bit more specific, then it goes under that, for
example "Core.Text.Encoding". This addresses the problem of "where does
this function I wrote go" much better than the current system we have
(SysUtils, StrUtil, LCLProc, LazUTF8).

> Not really - it would be easier only until the point when someone else
> than the original inventor of the naming system comes with something not
> fitting either of the categories perfectly (guaranteed to happen sooner or
> later). You may be perfectly clear where it belongs, while somebody else
> may have a different view / expectation. There is no golden rule, as
> simple as that. The only way to keep one consistent system is having the
> system managed centrally, but that doesn't work if there are at least
> three independent sources (FPC, Delphi and Lazarus).

Okay so what I am saying is clean it up, which is where you're going there
with centrally managed. The hub is "Core" and things go under that like
Networking, Graphics, Files, Text and so on. If anyone write a function
that checks for something having to do with the a file, like a funtion
FileCompare, then it goes somewhere under "Core.Files". It actually make
picking units to put stuff in easier.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20160127/a6fe06c1/attachment.html>