Recent

Author Topic: RTL Namespaces  (Read 1284 times)

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 10175
  • FPC developer.
Re: RTL Namespaces
« Reply #15 on: June 16, 2022, 11:04:35 am »
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

  • Hero Member
  • *****
  • Posts: 4764
Re: RTL Namespaces
« Reply #16 on: June 16, 2022, 11:37:16 am »
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


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: 4308
  • Compiler Developer
Re: RTL Namespaces
« Reply #17 on: June 17, 2022, 09:13:37 am »
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

  • Hero Member
  • *****
  • Posts: 4764
Re: RTL Namespaces
« Reply #18 on: June 17, 2022, 10:09:42 am »
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
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

deadserious

  • New member
  • *
  • Posts: 8
Re: RTL Namespaces
« Reply #19 on: June 17, 2022, 04:41:51 pm »
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

  • Hero Member
  • *****
  • Posts: 4308
  • Compiler Developer
Re: RTL Namespaces
« Reply #20 on: June 19, 2022, 01:24:26 pm »
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

  • Administrator
  • Hero Member
  • *
  • Posts: 10175
  • FPC developer.
Re: RTL Namespaces
« Reply #21 on: June 19, 2022, 01:26:11 pm »
I'd be interested in the opposite, a tool to strip namespaces from delphi units.


Thaddy

  • Hero Member
  • *****
  • Posts: 11774
Re: RTL Namespaces
« Reply #22 on: June 20, 2022, 02:39:52 pm »
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)
Black themes should be banned.

deadserious

  • New member
  • *
  • Posts: 8
Re: RTL Namespaces
« Reply #23 on: June 21, 2022, 08:53:45 pm »
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

  • Hero Member
  • *****
  • Posts: 4308
  • Compiler Developer
Re: RTL Namespaces
« Reply #24 on: June 22, 2022, 09:07:58 am »
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).

 

TinyPortal © 2005-2018