<div dir="ltr"><div class="gmail_extra"><div class="gmail_extra">Tomas,</div><div class="gmail_extra"><br></div><div class="gmail_extra">> Alright. So what is the authorship of the default units and how does it</div><div class="gmail_extra">> fit to Delphi compatibility?</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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).</div><div class="gmail_extra"><br></div><div class="gmail_extra">> Nobody prevents vendors to use their namespace now, right?</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">> The reason of current distribution is primarily due to multiple sources.</div><div class="gmail_extra">> See <a href="http://wiki.freepascal.org/Unit_categorization">http://wiki.freepascal.org/Unit_categorization</a> (now certainly</div><div class="gmail_extra">> incomplete, but still showing the point). Certain functionality gets to</div><div class="gmail_extra">> the FPC codebase due to compatibility with Delphi, etc., other stuff is</div><div class="gmail_extra">> added by us due to missing functionality (which may get added under a</div><div class="gmail_extra">> different name and to a different unit in Delphi later), etc. Lazarus</div><div class="gmail_extra">> decides on what to add where independently based on their needs. And so</div><div class="gmail_extra">> on. How could namespaces solve that?</div><div class="gmail_extra"><br></div><div class="gmail_extra">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).</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">> Not really - it would be easier only until the point when someone else</div><div class="gmail_extra">> than the original inventor of the naming system comes with something not</div><div class="gmail_extra">> fitting either of the categories perfectly (guaranteed to happen sooner or</div><div class="gmail_extra">> later). You may be perfectly clear where it belongs, while somebody else</div><div class="gmail_extra">> may have a different view / expectation. There is no golden rule, as</div><div class="gmail_extra">> simple as that. The only way to keep one consistent system is having the</div><div class="gmail_extra">> system managed centrally, but that doesn't work if there are at least</div><div class="gmail_extra">> three independent sources (FPC, Delphi and Lazarus).</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div></div></div></div>