#1 2020-11-06 12:53:22

SteveNew
Member
Registered: 2020-04-23
Posts: 2

Fully qualified unit names - please

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

Offline

#2 2020-11-06 15:59:25

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,659
Website

Re: Fully qualified unit names - please

We want to be compatible with Delphi 7 and 2007, and FPC so using Winapi.Windows and System.SysUtils is not possible for us.

I don't see why plain Windows and SysUtils reference is a problem.
It is easier to properly set the project settings than to patch the mORMot units.

Using $ifdef is not a solution, because it is ugly and not mandatory here.

Offline

#3 2020-11-06 17:06:05

SteveNew
Member
Registered: 2020-04-23
Posts: 2

Re: Fully qualified unit names - please

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 big_smile

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.

Offline

Board footer

Powered by FluxBB