Hello together!

I'm pleased to announce the implementation of a new feature: default namespaces.

As you may know FPC supports the use of dots/points/periods (".") inside unit (and program/library) names which allows to avoid name collisions with a syntax similar to other languages like Java and C# (and somewhat also to C++'s "::"). Unlike those languages in FPC such names don't introduce a real namespace system, so you can't do a "uses MyUnits.*" or something like that to have both units MyUnits.FancyFuncs and MyUnits.FoobarStuff included. Nevertheless the prefix of such a unit (in my example "MyUnits") is called a namespace.

For some users it might be cumbersome however to write the complete names (even though their IDE of choice might support them here) or maybe they have different sets of units with same names and interfaces, but different namespaces (e.g. ProductX and ProductY which contain wrappers units for the 3rd party products X and Y with a common interface). Of course in the latter case these can be switched using ifdefs or some creative usage of macros, but that can be done simpler.

Enter default namespaces.

The compiler is told about a default namespace using the new -FN<x> parameter, whereby <x> is a valid Pascal identifier for a namespace (e.g. "MyUnits" or "FCL.XML" or "FCL.Web.Base"). Like with all similar -F parameters -FN only takes a single value, but can be specified multiple times.
Now if the compiler encounters a unit name in the uses declaration it first searches for the unit as-is (first for a compiled unit, then for the sources). If the unit wasn't found then it walks the list of default namespaces, prepends them to the provided unit name as a prefix (with "." as a separator) and then again searches first for a compiled unit and then the sources.
If the unit was found then all symbols are available as usual. Additionally you can use a full or partial unit name:
- assume a unit XMLReader which is part of the default namespace FCL.XML with the symbol ReadXML
- ReadXML can be addressed either as ReadXML, XMLReader.ReadXML or FCL.XML.XMLReader.ReadXML
- if FCL is also given as a default namespace then XML.XMLReader.ReadXML is valid as well

The default namespace functionality is compatible with the -Un switch: E.g. if unit Blubb resides in foo.bar.pp then supplying the default namespace "foo" and using the unit "Bar" (with -Un active) will result in the file foo.bar to be found and used correctly.

The feature is Delphi compatible (aside from the parameter of course :P ).

Known issue:
Assume the following situation:
- unit ./somepath/someunit.pp
- unit ./somens.someunit.pp
- unit search path ./somepath and ./
- unit output path ./whatever
- default namespace "somens"
Now by design the unit someunit will be picked up. However if the search path ./somepath is removed or the unit source is removed then the compiler *will not* pick up somens.someunit.pp as long as someunit.ppu is in the unit output directory even if -B is specified. The reason for this is as-designed functionality to keep using the compiled unit if the source is not available (at least as long as no change to a dependant unit would trigger a required recompilation of said unit).

Regards,
Sven

On Sat, May 5, 2018 19:23, Sven Barth via fpc-pascal wrote:

Hi Sven,

.
.

(e.g. "MyUnits" or "FCL.XML" or "FCL.Web.Base"). Like with all similar -F parameters -FN only takes a single value, but can be specified multiple times.

.
.

I'm not sure what are 'all similar -F parameters', but many -F parameters allow multiple semicolon separated values.

Tomas

Sven Barth wrote

Hello together! I'm pleased to announce the implementation of a new feature: default namespaces.

Great !! Nice job, Sven :)

All looks logical to me. One question only:

Is there a reason you didn't implement a global directive:

{$NAMESPACE somens}

or is this still planned ?

Regardless of the answer: Congratulations on a nice job :)

Michael.

In our previous episode, Michael Van Canneyt said:

How would this work anyway? Same problem like where to put a global $define ?

Not sure what you mean ?

{$NAMESPACE FMX}
interface

uses controls; -> Resolves to FMX.Controls ?

Michael.

In our previous episode, Michael Van Canneyt said:

I took global as program global. Seems you mean unit global. That is of course not a problem.

Michael Van Canneyt schrieb am Sa., 5. Mai 2018,
21:24:

Does Delphi support this? If not, that is your answer: no real need for it (fair remark: I'm currently freshly home from a club and thus quite a bit drunk).

Regards,
Sven

Cool I guess. Kind of seems not very important at all though. FPC lacks compatibility with current Delphi in various other far more significant areas...

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On May 6, 2018, at 12:23 AM, Sven Barth via fpc-pascal wrote: For some users it might be cumbersome however to write the complete names (even though their IDE of choice might support them here) or maybe they have different sets of units with same names and interfaces, but different namespaces (e.g. ProductX and ProductY which contain wrappers units for the 3rd party products X and Y with a common interface). Of course in the latter case these can be switched using ifdefs or some creative usage of macros, but that can be done simpler.

I don’t understand what this is for because “namespaces” in FPC are optional anyways right? I’ve only used them to resolve name conflicts but if they’re optional then doesn’t that implicitly imply they're default also? Maybe a concrete example would help to explain.

Regards,
Ryan Joseph

On May 6, 2018, at 8:16 AM, Ben Grasset wrote: Cool I guess. Kind of seems not very important at all though. FPC lacks compatibility with current Delphi in various other far more significant areas...

Anonymous functions? ;)

Regards,
Ryan Joseph

He meant:
If you use units with namespaces and you can't use the -FN option, then it becomes cumbersome to write them. Then a unit directive would be nice to have.

Mattias

But does FPC have actual namespaces besides prefixing unit names? What exactly are "units with namespaces”?

Regards,
Ryan Joseph

Ben Grasset schrieb am So., 6. Mai 2018, 03:16:

Cool I guess. Kind of seems not very important at all though. FPC lacks compatibility with current Delphi in various other far more significant areas...

It was something that was relatively easy to implement and what some people complained about that we don't have.
Also pas2js already implemented it which bothered me a bit :P

Regards,
Sven

Ryan Joseph schrieb am So., 6. Mai 2018, 09:16:

They are also named "dotted units" and as I wrote in y announcement mail Object Pascal doesn't have namespaces in the sense of languages like C#, C++ or Java that allow for deep hierarchies and such. The namespaces in Object Pascal are merely a convenience thing. E.g. Delphi prefixed many of the existing units (like SysUtils became System.SysUtils, Windows became WinApi.Windows and Forms became VCL.Forms (or so)). They did this so that FireMonkey units can share unit names with the VCL (e.g. FMX.Forms). But to keep backwards compatibility with old code Delphi projects have by default their default namespace list set to something like "System, WinApi, VCL" so that such code continues to compile.

In FPC we currently don't use dotted unit names much, but maybe that will change in the future.

Regards,
Sven

Tomas Hajny schrieb am Sa., 5. Mai 2018, 19:52:

Then that's something I'll have to add then as well ;)

On May 6, 2018, at 2:40 PM, Sven Barth via fpc-pascal wrote: The namespaces in Object Pascal are merely a convenience thing. E.g. Delphi prefixed many of the existing units (like SysUtils became System.SysUtils, Windows became WinApi.Windows and Forms became VCL.Forms (or so)). They did this so that FireMonkey units can share unit names with the VCL (e.g. FMX.Forms). But to keep backwards compatibility with old code Delphi projects have by default their default namespace list set to something like "System, WinApi, VCL" so that such code continues to compile.

So I could use this feature if I used dotted file names like Utils.Foo.pas? I never thought of doing that before so this is al news to me.

Regards,
Ryan Joseph

In our previous episode, Mattias Gaertner said:

He meant: If you use units with namespaces and you can't use the -FN option, then it becomes cumbersome to write them. Then a unit directive would be nice to have.

Yes, but both the directive and the uses would be a modification anyway.

I can imagine that if you have an includefile with defines, that it is iuseful.

In our previous episode, Sven Barth via fpc-pascal said:

In FPC we currently don't use dotted unit names much, but maybe that will change in the future.

Afaik FV and LCL have conflicts.

Sven Barth wrote

[...] In FPC we currently don't use dotted unit names much, but maybe that will change in the future.

Would be good if all units could be prefixed to make a pattern, like `fpc.web, fpc.xml, ...` but I know that we need to maintain the compatibility with Delphi using the same names...
However, Lazarus could do that — we just need a replace in the code.

By the way, good work!

Best,
Marcos Douglas

i,
 
LCLIntf, LCLProc, LCLType isn't enough? I will use dotted units only if there will be absolutely no other way around. I believe it can be useful but I don't think it's "must have" (when I don't consider Delphi compat.).   
V.
______________________________________________________________

Sven Barth wrote

[...] In FPC we currently don't use dotted unit names much, but maybe that will change in the future.

Would be good if all units could be prefixed to make a pattern, like `fpc.web, fpc.xml, ...` but I know that we need to maintain the compatibility with Delphi using the same names...
However, Lazarus could do that — we just need a replace in the code.

By the way, good work!

Best,
Marcos Douglas

Vojtěch Čihák wrote

i, LCLIntf, LCLProc, LCLType isn't enough? I will use dotted units only if there will be absolutely no other way around.

There are many others without LCL prefix...

I believe it can be useful but I don't think it's "must have" (when I don't consider Delphi compat.).

I've said "would..." and "could..."

Marcos Douglas

In our previous episode, Marcos Douglas B. Santos said:

Yes. And you don't want to keep long lists of all prefixes that you want to have, so I think it is more for exceptions where there are clashes than for mass transition to this scheme. To be honest I always found it annoying in Delphi, and use old names and prefixes as much as possible.

But it does resolves problems like Lazarus currently (afaik) not installing FV because units conflict.

E.g. The conflicting units can get a prefix lcl. and Lazarus automatically adds the prefix parameter for projects that use LCL.

Similarly for other packages that have very common names.

Only projects that really use both such packages will have to use the longer form.

Done in r38939. :)

Regards,
Sven

[...] I'm pleased to announce the implementation of a new feature: default namespaces.

Nice!
Dotted unit names without that felt so stupid.

[...] Nevertheless the prefix of such a unit (in my example "MyUnits") is called a namespace.

Fun fact: Delphi help sometimes calls it "unit scope names". ;)

[...] The compiler is told about a default namespace using the new -FN<x> parameter,

Lazarus now checks for the -FN flag in the custom compiler options.

Can you add a message similar to "Using unit path:"? Then Lazarus can find out what default namespaces are defined by the fpc.cfg.

Mattias

Mattias Gaertner schrieb am Mo., 7. Mai 2018,
10:35:

So you are one of those that supported/wanted that feature :P

Maybe we should use that terminology as well *shrugs*

Can do that :)

Regards,
Sven

In our previous episode, Sven Barth via fpc-pascal said:

Delphi uses semicolons :-)

Marco van de Voort schrieb am Mo., 7. Mai 2018, 11:51:

FPC's parameters need to be consistent with its other arguments. If none of the other arguments would have supported lists I wouldn't have introduced that just now. Also if the other arguments would have used "," I wouldn't have started to use ";" either.
That said I personally prefer to not use these list forms of the arguments anyway. :)

Regards,
Sven

Done in r38944. :)

Regards,
Sven

Thanks! Appreciated.

Mattias

No, it's not a "must have" or "must use", but it does have it's uses. As was already pointed out, Delphi uses it for backwards compatibility and allows two completely different framework to use the same unit names. eg: VCL.Forms and FMX.Forms.

It could be used in FPC or your own library too - instead of using IFDEFs and Include files for platform specific code, where they share the same interface. So now you can use namespaces instead and specify the namespace platform when you compile - similar to what you would have done with Compile Defines.

Regards,
Graeme