RTL Namespaces

[marcov]

Once units are namespaced (and assuming that their base name stays the same) you can simply use the already existing -FN option to define default namespaces. E.g. -FNSystem with a unit Classes will lead to the compiler looking for both System.Classes and Classes. So you can keep the source the same, but just adjust the compilation parameters.

(and that is also what I do on the delphi side. But not everbody does, and in my experience the last 5-8 years the bulk of Delphi users seem to  have moved from the eternal D7 to unicode versions, and pretty new ones even)

[MarkMLl]

Allowing that this is probably a minority position, but could I highlight a use case and ask whether any change relating to namespaces etc. would cause problems.

For some years I have used a program organisation where a library- perhaps a backend to interface to a specific physical instrument- can be linked either statically (ordinary "uses" clause) or dynamically (run-time dynamic loading of a .so or .dll).

If the linkage is static, the library (e.g. Dso112a) appears to be a unit and functions it exports may be accessed as e.g. Dso112a.MagicNumber().

If the linkage is dynamic, the library is an instance of a class wrapping the .so or .dll, loading the binary and finding entry points at first use. Exported functions/methods may again be accessed as e.g. Dso112a.MagicNumber() where in this case Dso112a is the name of an instance.

Could the introduction of namespaces mess up this convention? If so, is there an elegant workaround?

MarkMLl

[PascalDragon]

Could the introduction of namespaces mess up this convention?

Why should it? We're talking about introducing namespaces for the RTL, FCL, LCL units, not your own. And the mechanisms for these are already in place since 3.0.0 (namespace support itself) and 3.2.0 (the -FN-parameter).

[MarkMLl]

Could the introduction of namespaces mess up this convention?

Why should it? We're talking about introducing namespaces for the RTL, FCL, LCL units, not your own. And the mechanisms for these are already in place since 3.0.0 (namespace support itself) and 3.2.0 (the -FN-parameter).

Thanks, I was just being very cautious :-)

MarkMLl

[deadserious]

What i think I'll do is build a tool that updates RTL units with namespaces and rebuilds the libraries so that people who wish too have a namespaced rtl can.  It would just require running the tool after updating fpc.

[PascalDragon]

So you expect third party providers to cater to both, those that want to use namespaces and those who don't? Also units are provided precompiled in the installers on purpose cause one doesn't have to fiddle with building FPC oneself. Also someone would need to maintain that mechanism.
There's no sense in making things more complicated than they are.

[marcov]

I'd be interested in the opposite, a tool to strip namespaces from delphi units.

[Thaddy]

I'd be interested in the opposite, a tool to strip namespaces from delphi units.

I have one. It is simple but not complete: does not parse defines inside the uses clause, does not parse implementation yet and is single file.
I will see if I can find it. It dates from the introduction of namespaces in Delphi.
I always wanted to rewrite it with RegExpr, if I remember correctly. (It is old stuff)

[deadserious]

So you expect third party providers to cater to both, those that want to use namespaces and those who don't? Also units are provided precompiled in the installers on purpose cause one doesn't have to fiddle with building FPC oneself. Also someone would need to maintain that mechanism.
There's no sense in making things more complicated than they are.

I guess maybe I'll need to provide my own distro then lol.

[PascalDragon]

I guess maybe I'll need to provide my own distro then lol.

Which you are definitely free to do, but please note that especially once dynamic packages are fully supported this might lead to problems there as well (not to mention that the whole of Lazarus is geared towards what is provided by FPC itself, so you need to keep around both your own as well as a standard distribution to be able to build Lazarus).

[DonaldShimoda]

So, there´s a strong decision in no support for this naming. Or any change on this (old) topic? I have a lot of Delphi 10 code to use on FPC for arm. Must put a lot of ifdef? Or theres a more elegant solution?

[marcov]

No ifdef, just remove all namespaces in the source, and then set the default namespace in the delphi IDE to compensate that, and presto it works on both.

[KodeZwerg]

In Delphi I do since years....

Code: Pascal  [Select][+][-]

1. {$IF Defined(DCC) or Defined(VER210) or Defined(VER200) or Defined(VER190) or Defined(VER185) or Defined(VER180) or Defined(VER170) or Defined(VER160) or Defined(VER150) or Defined(VER140) or Defined(VER130) or Defined(VER120) or Defined(VER100) or Defined(VER90) or Defined(VER80)}
2.   {$DEFINE Delphi} { Delphi }
3. {$IFEND}
4.  
5. {$IF Defined(DELPHI) and Declared(CompilerVersion) and (CompilerVersion >= 23)}
6.   {$DEFINE NameSpace} { Delphis NameSpace feature (eg Winapi.Windows instead of Windows) }
7. {$IFEND}
8.  
9. {$IF Defined(WIN32) or Defined(WIN64) or Defined(MSWindows)}
10.   {$DEFINE Windows} { We are on Windows }
11. {$IFEND Windows}

...via include file

Since I started not that long ago to use also FreePascal my unit header looking like this (exemplary)

Code: Pascal  [Select][+][-]

1. {$IFDEF DELPHI}
2.   {$IFDEF NameSpace}
3.     {$IFDEF Windows}
4.       Winapi.Windows,
5.     {$ENDIF Windows}
6.     System.SysUtils, System.Classes,
7.     Vcl.Graphics, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.ExtCtrls, Vcl.StdCtrls,
8.   {$ELSE NameSpace}
9.     {$IFDEF Windows}
10.       Windows,
11.     {$ENDIF Windows}
12.     SysUtils, Classes,
13.     Graphics, Controls, Forms, Dialogs, ExtCtrls, StdCtrls,
14.   {$ENDIF NameSpace}
15. {$ENDIF DELPHI}
16. {$IFDEF FPC}
17.   {$IFDEF Windows}
18.     Windows,
19.   {$ENDIF Windows}
20.   SysUtils, Classes,
21.   Graphics, Controls, Forms, Dialogs, ExtCtrls, StdCtrls,
22. {$ENDIF FPC}

[DonaldShimoda]

No ifdef, just remove all namespaces in the source, and then set the default namespace in the delphi IDE to compensate that, and presto it works on both.

Not so easy. VCl and FMX have sense on delphi. And i prefer to not lose delphi compatibility.

So ifdef is the only way.

[marcov]

No ifdef, just remove all namespaces in the source, and then set the default namespace in the delphi IDE to compensate that, and presto it works on both.

Not so easy. VCl and FMX have sense on delphi. And i prefer to not lose delphi compatibility.

For me FMX never made sense on Delphi. btw: I started originally with this scheme because I had XE at home, but XE3 at work, nothing to do with FPC.