You are not logged in.
- Topics: Active | Unanswered
Pages: 1
#1 Re: Source Code repository » Fully qualified unit names - please » 2020-11-06 17:06:05
I understand - since the survey showed still 30% of the people who responded are using D7 or D2007 - personally I do wonder why they haven't spend the time and effort to move on - that being ether Delphi unicode versions or FPC/Lazarus.
The backward compatibility is a double-edge sword - and I would hope that the code could be cleaned up of $ifdef and force some to rethink/refactor their code in general - the reason I did the issue was because our code broke with a mORMot commit in January - and now I want to move forward 
Not using aliases, was partly a political and a build environment decision - and it is actually quite helpful and nice to have the full "namespace" provided - and the compile does not need to resolve them (probably only measurable in gigantic projects)
I will look into what mORMot2 brings - the EKON slides looked very promising - more clean and readable code. And I love the new naming - TSQLxxx has always put me off.
Thanks Anoud, for taking the time to respond.
#2 Source Code repository » Fully qualified unit names - please » 2020-11-06 12:53:22
- SteveNew
- Replies: 2
We do not use any unit alias' and do try to follow the norm of using fully qualified names - both for readability, claimed performance and our code grows, so exact and meaningful unit names are a must.
Can see that mORMot2 also is gone down the route of finally splitting things up into meaningful named units. Thanks!
I just did an issue on GitHub asking for the use of fully qualified name in 1.8 - closed because a discussion with more detail here could be helpful.
Today we change 14 files to satisfy for the need for fully qualified names, when we update our mORMot installations, so for that reason I created the issue - but I would also be happy to do a pull request.
But since I am doing this only in relation to Delphi - haven't used FPC/Lazarus for many years - I am curious if there are any concerns or reason not to implement that change - that I would consider a best practice?
In short - all unit references should be changed:
Windows -> Winapi.Windows
SysUtils -> System.SysUtils
and so forth.
/Steffen
Pages: 1