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

[Tomas Hajny]

On Wed, January 27, 2016 08:57, Anthony Walter wrote:


Hello,

> I see the many benefits of dotted namespace units.
>
> 1) Authorship.
>
> Instead of using cryptic prefixes (Rx, Syn, Id, and so on) if we promoted
> the use of namespaces we might someday the full names denoting ownership
> more clearly. That and there would be less me creating unit names
> conflicts (My StrTools vs your StrTools).

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


> 2) Discovery
>
> If you have groups of related functionality from a vendor it's easier to
> discover with code insight tools using dots. For example Indy (dot)
> <browse
> list and pick> Log (dot) <browse logging routines and pick> Debug (Out of
> Indy.Log.Files, Indy.Log.Stream, Indy.Log.Event)

Nobody prevents vendors to use their namespace now, right?


> 3) Organization
>
> I have a set of string manipulation routines. The LCL has a set of string
> manipulation related routines in a few units. Other people have string
> manipulation routines in their units. Wouldn't it be nice if I could find
> all string related routines under a one category like "Text", rather than
> trying to find the string functions I need either from SysUtils, or
> StrUtils, or LCLProc, LazUTF8, or Regex, or MyOwnStrUtils. When Core.Text
> ought to cover all the basics of Text, Core.Regex would cover regular
> expression, and maybe we could add a Core.Text.Encoding if needed.

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?


> 4) Maintenance
>
> I don't know about you, but when working with the LCL I often have trouble
> deciding where some new or extra functionality should go. There was a
> recent issue with this and the IsIdentifier function in mantis. Did it go
> into LCLProc, or StrUtils, or where? With buckets like Core.Text, it would
> sure make it easier to decide.

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


> 4) Grouping
>
> Wouldn't it be nice if controls came under their own group first rather
> than at the end? Currently people names units things like ShellCtrls,
> GridCtrls, or DbCtrls. Wouldn't it be nice if you could find all possible
> control units in source code by simple typing "Lazarus.Forms.Controls
 .
 .

I'm not in the position to comment proposals for Lazarus unit names, so
I'll skip this one.

Just my 2 cents...

Tomas