I'm not sure I understand you. I mean that I must name a file "System.Time.Timer.pas" to make its unit be "System.Time.Timer." I do not think the directory structure should necessarily coincide with any concept of namespace, but I am surprised there is no way to keep from having rather long file names, and fake namespace names that are slightly misleading.
The dots in "System.Time.Timer.pas" are part of the file name. They form a namespace but it has nothing to do with directory structures.
In Java a similar source file Timer.java would be in directory System/Time/. In Java the namespace is built using a directory structure.
I also don't understand you. Why you write about directory structures here? Why would you need fake namespace names that are slightly misleading?
For the project management issues, you could try the project group.
I know. However it is FPC with the fake namespace names. The file naming system as it exists now is not really a "namespace." Everything is still a flat hierarchy with names that have periods in them. As I was told last time I brought this up it is impossible to just type "uses Timer" although Delphi properly implements namespaces and searching. The naming restrictions may still be in place.
Citing Delphi's "Namespace" documentation is misleading, cause it's for Delphi.Net even though it's not explicitely mentioned there. You can see this in Delphi Tokyo's documentation where at the end it mentions "assembly" which is .Net only. What non-.Net Delphi implements and FPC supports as well are so called Unit Scope Names and as Marco said trunk even supports the option to pass unit scope name prefixes using the -FN<x> parameter.
I just reread it and I don't think I wandered into the Delphi.NET documentation. Delphi doesn't have true namespaces, but gets fairly close with the ability to include the "A.B.C." by default.
If you go down to the "Multi-unit Namespaces" section in the first link it looks like using "A.B.C" is supported, removing the need for the compiler switch. The documentation then goes on to explain this only works with source files or .dcu files implying the concept of namespaces doesn't make it to object files.
There is no reason to lowercase file names. You can still find a file in a search path if you do not know how it is cased: you list all files, lowercase the names in memory, and compare them to your target string after lowercasing it.
Yes, there is a reason to do it the way FPC does it currently: case sensitive file systems can have files with the same lower case name in the same location. E.g. there could be a StdCtrls and a stdctrls in the same directory. By lower casing the file name it's not clear (for the user) which file is picked especially as the order is depending on the OS. By searching the file in a specific casing order (as-is, lower case, upper case) this is handled in a documented and cross platform way.
Please note that this can also happen on Windows. E.g. if you use a case sensitive file system (like Ext for which there are drivers) or with network file systems.
If you enumerate the files in a directory you're free to try to match them respecting case first before lowercasing them and in the same order that is already documented. It could work exactly like the existing scheme save the user's choice of name doesn't matter.
The existing name resolution scheme has the problem you mention. I don't see how this is unique to any other way of resolving names. What "solves" it is the IDE's (not the compilers!) choice to lowercase names it saves by default. Personally this is a very, very strange solution to a problem that does not need to exist:
I think it was recommended by someone else that FPC enforce unique identifiers in some way. This would mean compilation would proceed uniformly regardless of filesystem.
Recent
