Recent

Author Topic: RTL Namespaces  (Read 1596 times)

deadserious

  • New member
  • *
  • Posts: 8
RTL Namespaces
« on: June 15, 2022, 05:23:18 am »
I'm trying to compile some Delphi units in FPC and running into an issue where the System namespace is unknown.  Units like System.SysUtils, System.DateUtils, System.IOUtils, etc aren't found.  I'm guessing based on the file names in the units/rtl folder you haven't yet namespaced your RTL units in FPC?

How can we tell FPC that System.* should alias to units without System namespace?  Or is there a different RTL I should be pointing to that is already namespaced to match Delphi?

PascalDragon

  • Hero Member
  • *****
  • Posts: 4765
  • Compiler Developer
Re: RTL Namespaces
« Reply #1 on: June 15, 2022, 09:04:11 am »
I'm guessing based on the file names in the units/rtl folder you haven't yet namespaced your RTL units in FPC?

Correct.

How can we tell FPC that System.* should alias to units without System namespace?

You can't.

Or is there a different RTL I should be pointing to that is already namespaced to match Delphi?

There isn't.

deadserious

  • New member
  • *
  • Posts: 8
Re: RTL Namespaces
« Reply #2 on: June 15, 2022, 09:29:10 am »
If I were to take on the effort of renaming RTL units to their namespace, would that be a welcome PR for the team? 

Or is there no interest in Delphi namespace compatibility?

Thaddy

  • Hero Member
  • *****
  • Posts: 12209
Re: RTL Namespaces
« Reply #3 on: June 15, 2022, 09:46:25 am »
If the dot would be supported in FPC's macro facility, it could come a long way.
Manuals, manuals, manuals first.
You have incompetence and sheer incompetence.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 10402
  • FPC developer.
Re: RTL Namespaces
« Reply #4 on: June 15, 2022, 10:14:35 am »
It's a well known issue.  If a change will be made, it will only be made near a major version transition to keep the transition period as short as possible, I will put it on the major version checklist.

However there are probably also certain legacy target concerns, since it possibly eats into their maximum filepath. That discussion still must be had (short term desirability).

(I hope that since you use Delphi, I don't have to tell you how intrusive those changes are)

I simply work the other way, I enter the skip namespace tag in Delphi, and rename all my units on that side.

PascalDragon

  • Hero Member
  • *****
  • Posts: 4765
  • Compiler Developer
Re: RTL Namespaces
« Reply #5 on: June 15, 2022, 02:19:59 pm »
If I were to take on the effort of renaming RTL units to their namespace, would that be a welcome PR for the team?

While we do think about introducing namespaces in the future as marcov said this is not a topic that is simply done, mainly because we also support operating systems that have a 8.3 file name limit. So, no, a PR would not be welcome for this as there are quite some questions to solve.

Or is there no interest in Delphi namespace compatibility?

It won't be fully compatible anyway. E.g. unit Contnrs might just as well be placed in FCL.Contnrs instead of System.Contnrs (I'm not saying that it will be, but it's at least a possibility). And the LCL units on the other hand will very likely use LCL as prefix instead of VCL.

Thaddy

  • Hero Member
  • *****
  • Posts: 12209
Re: RTL Namespaces
« Reply #6 on: June 15, 2022, 03:35:50 pm »
The latter is already no problem
Code: Pascal  [Select][+][-]
  1. {$macro on}{$define vcl:=lcl}
As I wrote, it is only about the dot....
IOW then you can make prefixes disappear...

I asked Jonas for that macro extension a couple of years ago, but he dismissed that.
Now it bites,  again...
« Last Edit: June 15, 2022, 03:41:15 pm by Thaddy »
Manuals, manuals, manuals first.
You have incompetence and sheer incompetence.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 10402
  • FPC developer.
Re: RTL Namespaces
« Reply #7 on: June 15, 2022, 03:40:36 pm »
It won't be fully compatible anyway. E.g. unit Contnrs might just as well be placed in FCL.Contnrs instead of System.Contnrs (I'm not saying that it will be, but it's at least a possibility). And the LCL units on the other hand will very likely use LCL as prefix instead of VCL.

I surely hope not ;)

jcmontherock

  • Full Member
  • ***
  • Posts: 153
Re: RTL Namespaces
« Reply #8 on: June 15, 2022, 04:23:43 pm »
However, for example, you can use "System.Delete()" to execute a procedure if you already have a "Delete()" procedure in your application. It's a little namespace.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 10402
  • FPC developer.
Re: RTL Namespaces
« Reply #9 on: June 15, 2022, 04:30:39 pm »
System is also the name of the always-there unit.  This has worked since turbo pascal times.

deadserious

  • New member
  • *
  • Posts: 8
Re: RTL Namespaces
« Reply #10 on: June 16, 2022, 02:48:22 am »
I simply work the other way, I enter the skip namespace tag in Delphi, and rename all my units on that side.

Since anonymous methods are now supported, I'm trying to check compatibility with all of my open source libraries. They all already use namespaced units. I'd rather not despecify in my code and instead spend my time contributing to get fpc up to speed.

But if the work will end up not being accepted, it's not going to be worth my time.
« Last Edit: June 16, 2022, 02:52:41 am by deadserious »

deadserious

  • New member
  • *
  • Posts: 8
Re: RTL Namespaces
« Reply #11 on: June 16, 2022, 02:51:41 am »
It won't be fully compatible anyway. E.g. unit Contnrs might just as well be placed in FCL.Contnrs instead of System.Contnrs (I'm not saying that it will be, but it's at least a possibility). And the LCL units on the other hand will very likely use LCL as prefix instead of VCL.

I'm not expecting VCL.* to be compatible with LCL.* lol.

But like units in the RTL should be namespaced to match with Delphi imo.

It sounds like you disagree. It's been that sentiment that has kept me from fpc for so long.

avra

  • Hero Member
  • *****
  • Posts: 2385
    • Additional info
Re: RTL Namespaces
« Reply #12 on: June 16, 2022, 08:33:40 am »
I'm not expecting VCL.* to be compatible with LCL.* lol.

But like units in the RTL should be namespaced to match with Delphi imo.

It sounds like you disagree. It's been that sentiment that has kept me from fpc for so long.
I do not see it as a problem if some ifdefs or macros can jump in and help. It might even be that at the end most of the work is already done and transparent for you. There will never be a 100% compatibility, especially when FPC has to support embedded targets like AVR and run on old ones like DOS. But the expectation to be able to write code that compiles on both Delphi and FPC with little effort remains.
« Last Edit: June 16, 2022, 08:35:59 am by avra »
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

MarkMLl

  • Hero Member
  • *****
  • Posts: 5596
Re: RTL Namespaces
« Reply #13 on: June 16, 2022, 09:55:38 am »
However, for example, you can use "System.Delete()" to execute a procedure if you already have a "Delete()" procedure in your application. It's a little namespace.

System is also the name of the always-there unit.  This has worked since turbo pascal times.

I'd suggest that any departure from this which breaks compatibility with older FPC versions would be a very bad idea.

If we had to vote between keeping FPC compatible with both itself and older versions of Delphi, versus breaking compatibility in the name of chasing enhancements added to Delphi in its dotage, I'd be firmly on the side of tradition.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

PascalDragon

  • Hero Member
  • *****
  • Posts: 4765
  • Compiler Developer
Re: RTL Namespaces
« Reply #14 on: June 16, 2022, 11:01:22 am »
It won't be fully compatible anyway. E.g. unit Contnrs might just as well be placed in FCL.Contnrs instead of System.Contnrs (I'm not saying that it will be, but it's at least a possibility). And the LCL units on the other hand will very likely use LCL as prefix instead of VCL.

I surely hope not ;)

For units that are part of the FPC distribution it might indeed be less likely that they'll have a different namespace, but I already know that dynamic packages won't be compatible, because there I'll favor maintainability before compatibility.

However, for example, you can use "System.Delete()" to execute a procedure if you already have a "Delete()" procedure in your application. It's a little namespace.

It's the “namespace” provided by the System unit which is automatically used in every unit that isn't the System unit.

I'd suggest that any departure from this which breaks compatibility with older FPC versions would be a very bad idea.

If we had to vote between keeping FPC compatible with both itself and older versions of Delphi, versus breaking compatibility in the name of chasing enhancements added to Delphi in its dotage, I'd be firmly on the side of tradition.

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.

 

TinyPortal © 2005-2018