[Solved] Are there any file naming rules to save ampersand prefixed units?

[WooBean]

And that would be a great idea?

What does this Thaddism mean?

Am aware that current Lazarus has problem with saving unit "&begin" via "Save As ..." dialog - it allows such renaming but ignoring its own warning wrongly replaces references to renamed unit inside unit code to "begin".

It is only a part of keeping consistency of renamed identifiers being unit names and I am working on it - simple doing Lazarus a bit better, not a  great idea?   

[n7800]

Well, the final conclusion is:

save or rename units (projects) containg "&" prefix(es)  to file named without using ampersands (&).

Example:

unit "&begin.&end" will be saved in file named "begin.end.pas".

Yes, but keep all ampersands in the code (even if they are written for a non-keyword). That's my opinion.

[PascalDragon]

I agree that this method should not be recommended, that's why I said about mandatory warning the user and explicit advice not to use it. But for the sake of the ability to migrate old or incompatible code, it cannot be prohibited at all.

If it's a bug then backwards compatiblity is not relevant. And this is a bug.

[MarkMLl]

What does this Thaddism mean?

He means that the idea of having multiple dots in a filename is one which is likely to cause you problems.

MarkMLl

[n7800]

I agree that this method should not be recommended, that's why I said about mandatory warning the user and explicit advice not to use it. But for the sake of the ability to migrate old or incompatible code, it cannot be prohibited at all.

If it's a bug then backwards compatiblity is not relevant. And this is a bug.

Please read more carefully. I was talking about preserving ampersands in the code. And I agree with the automatic removal of the ampersand in the file name.

[PascalDragon]

I agree that this method should not be recommended, that's why I said about mandatory warning the user and explicit advice not to use it. But for the sake of the ability to migrate old or incompatible code, it cannot be prohibited at all.

If it's a bug then backwards compatiblity is not relevant. And this is a bug.

Please read more carefully. I was talking about preserving ampersands in the code. And I agree with the automatic removal of the ampersand in the file name.

Even rereading it, it's not really clear what exactly had been meant. But for the code itself I don't see a good reason to forbid it anyway especially as it would be an unnecessary complication of the parser.

[WooBean]

What does this Thaddism mean?

He means that the idea of having multiple dots in a filename is one which is likely to cause you problems.

MarkMLl

It is no choice situation for Lazarus. We have already "Generics.Collections" or "System.UITypes" and so on ... .

Currently implemented in Lazarus/FPC namespaces mechanism is more prone to wrong unit usage than it can be with more restricted dotted identifiers as it is in recent Delphi releases.

Some excerpt from Embarcadero or rather Marco Cantù ... .
 
"The reason for this extension is that unit names must be unique, and with more and
more units being provided by Embarcadero and by third party vendors, this became
more and more complex. All of the RTL units and the various other units that ship
as part of the product libraries now follow the dotted unit name rule, with specific
prefixes denoting the area, such as:
· System for core RTL
· Data for database access and the like
· FMX for the FireMonkey platform, the single-source multi-device architecture for
desktop and mobile
· VCL for the Visual Component Library for Windows"

Let's note that level of dotting in their world (Delphi) is quite often greater than 3.

[MarkMLl]

Suit yourself. But I say that- in the general case of filenames- multiple dots will bite you.

MarkMLl

[PascalDragon]

Suit yourself. But I say that- in the general case of filenames- multiple dots will bite you.

At work we regularily use multiple dots (though C++ and not (Object) Pascal) and so far there are no problems. And even for Object Pascal there are no problems. In fact the route for the FPC distribution is towards a variant with dotted unit names more compatible to current Delphi versions.

[TRon]

In fact the route for the FPC distribution is towards a variant with dotted unit names more compatible to current Delphi versions.

On that note, it is sometimes confusing what names are and aren't allowed. imho A name is a name (including the dot) so when I name my unit class.custom (or custom.class) I more or less expect the compiler to not complain about expecting an identifier.

Perhaps my expectations are unrealistic (perhaps because of my misunderstanding of what an identifier means in this regards) ?

[WooBean]

...
On that note, it is sometimes confusing what names are and aren't allowed. imho A name is a name (including the dot) so when I name my unit class.custom (or custom.class) I more or less expect the compiler to not complain about expecting an identifier.

Perhaps my expectations are unrealistic (perhaps because of my misunderstanding of what an identifier means in this regards) ?

Attached an example of renaming dotted identifiers using a code developed under Lazarus issue #41002.
Freedom of dotted  naming is quite wide - you can use any valid identifiers separated by dots. If you want to use Pascal keywords you must prefix them with "&".

 

[MarkMLl]

Suit yourself. But I say that- in the general case of filenames- multiple dots will bite you.

At work we regularily use multiple dots (though C++ and not (Object) Pascal) and so far there are no problems. And even for Object Pascal there are no problems. In fact the route for the FPC distribution is towards a variant with dotted unit names more compatible to current Delphi versions.

In that case let me be a bit more specific. I fully accept that a C++ or Object Pascal compiler which knows about dotted internal and external names for units (i.e. in the language and file contexts respectively) will probably handle them correctly. But on a typical unix (i.e. including Linux, Macs and so on) or Windows installation, I'd be prepared to bet that somewhere there is a program which will misparse a filename with an embedded dot in a way that will at least result in lost time and frustration.

MarkMLl

[TRon]

Attached an example of renaming dotted identifiers using a code developed under Lazarus issue #41002.
Freedom of dotted  naming is quite wide - you can use any valid identifiers separated by dots. If you want to use Pascal keywords you must prefix them with "&".

Yes, I get that but wasn't exactly my question 

fwiw I am using dotted unit-names the moment support for them was implemented.

Currently there is a clear definition of a unit-name (must be an identifier) and a clear definition of an identifier (which characters are allowed in a identifier).

You seem to make use of an alternative explanation for either one or both 

There are consequences when changing clear defined definitions to something else. Not to mention that a filename is just a filename that adheres to a complete other set of rules.

I am not that worried though because it seems to be an optional feature though not sure if it stays that way in the future.

[WooBean]

What is unclear in that:

https://www.freepascal.org/docs-html/ref/refse112.html#x233-25700016.2 ?

Dotted naming is no problem for FPC.
Lazarus has evolved to the state where some choises should be taken how to manage dotted identifiers and coressponding to them file names.

It seems to me that two rules can be approved:
1. identifiers can be dotted and will be kept in source code in used case letter (Pascal keywords are allowed but must be prefixed by "&");
2. file names corresponding to dotted identifiers will be kept in lowercase and can contain Pascal keywords (usage of "&" will be avoided).

Rule (1) is implemented.
Rule (2) is not implemented yet but has more pros than cons.

[TRon]

1. identifiers can be dotted and will be kept in source code in used case letter (Pascal keywords are allowed but must be prefixed by "&");

That has other implications such as for example for every other declaration in your code. (constants, variables etc)

It is currently also inconsistent because in case an identifier is allowed/defined to include a dot then the compiler should allow f.e. class.custom and not complain about expecting an identifier. Thus clearly this is currently not how things are implemented in the compiler.

Currently it seems the compiler threats a unit name as : either 'identifier' or 'identifier-[dot-identifier]'.

It has been a long time ago when I opted to use another solution instead, f.e. a designated 'space' so that you could 'import' a unit into that specific space and address it in code (I try to avoid the term name-space here because that has a far more profound implication and would probably be much harder to implement but in basics the opted suggestion is similar). That way the whole dotted unit name-thingy could have been avoided. Alas, Delphi compatibility.

2. file names corresponding to dotted identifiers will be kept in lowercase and can contain Pascal keywords (usage of "&" will be avoided).

The reason for me shaking the tree is because I don't like that. There should be no situation where you would need/require escaping unit names because you happen to choose a name that happens to be(come) a reserved word or in some future happens to clash with something else.

Other than that, I agree with the underlying thoughts you were trying to get across with your posts.