<div dir="ltr"><div class="gmail_extra">Michael,</div><div class="gmail_extra"><br></div><div class="gmail_extra">I see the many benefits of dotted namespace units.</div><div class="gmail_extra"><br></div><div class="gmail_extra">1) Authorship.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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).</div><div class="gmail_extra"><br></div><div class="gmail_extra">2) Discovery </div><div class="gmail_extra"><br></div><div class="gmail_extra">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)</div><div class="gmail_extra"><br></div><div class="gmail_extra">3) Organization</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">4) Maintenance</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">4) Grouping</div><div class="gmail_extra"><br></div><div class="gmail_extra">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 (dot)" and seeing things like "Grids, Shell, and Database" in the list of available units? Or maybe if you were dealing with web rendering toolkit it might be "Lazarus.Web.Controls". </div><div class="gmail_extra"><br></div><div class="gmail_extra">Perhaps you think this is too much typing, but code tools allows you to pick a value after a few keystrokes. Also consider the typing saved in not having to type TWebEdit or TWebGrid or TWebCheckBox or whatever you're calling your web engine visuals. You can simply call it TEdit and TGrid and TCheckbox. Think about all that typing saved (you only need to add a uses clauses once in a unit, but how many times do you need TEdit? Sometimes it's quite a lot.).</div><div class="gmail_extra"><br></div><div class="gmail_extra">If you want some examples, look at my Bare library structure:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><a href="http://www.baregame.org/#bare_game">http://www.baregame.org/#bare_game</a><br></div><div class="gmail_extra"><a href="http://www.baregame.org/#bare_geometry">http://www.baregame.org/#bare_geometry</a><br></div><div class="gmail_extra"><a href="http://www.baregame.org/#bare_text">http://www.baregame.org/#bare_text</a><br></div><div class="gmail_extra"><a href="http://www.baregame.org/#bare_text_xml">http://www.baregame.org/#bare_text_xml</a><br></div><div class="gmail_extra"><br></div></div>