Resolving procedure symbols directly?

[TRon]

But what is .xyz?

Anything you want it to read 

But... I did make a typo when presenting my case, see example.

AFAIK, there cannot be a dot in the names of units.

For sure you can. It exist for a while now (if even for Delphi compatibility)  and it is even possible to compile the RTL/FCL using dotted units. As mentioned by MarkMLI there are some issues under certain conditions.

edit: dotted units in 3.0.0, reference manual, wiki dotted RTL

Can you please give me some example code? Because i cannot get a grip on the concept, how can i workaround the unit/variable name colliding within the uses clause.

Sure, here we go.

Main unit (prg.pas):

Code: Pascal  [Select][+][-]

1. program prg;
2. uses myproc in 'myproc.xyz.pas'; // I initially forgot to mention that the filename also needs to include the .pas extension
3. begin myproc.myproc(1,false) end.
4.  

Library unit (myproc.xyz.pas):

Code: Pascal  [Select][+][-]

1. unit myproc.xyz;
2. interface
3. type TMyProc=procedure(a:integer;b:boolean);
4. var myproc:TMyProc;
5. implementation
6. end.
7.  

Thank you for the reasoning behind wanting to use the same name. But... if it is a drop in replacement then how did they go about it then ?

You can always opt to use a 'forwarding' unit, e.g. a unit that is only referring to another unit with contains the actual procedures variables and types. But also there is the same issue of name collision.

[TCH]

Anything you want it to read 

I knew that the xyz is a placeholder. It was the purpose i did not understand: is it scoping xyz, or xyz is a command, or alias?

For sure you can. It exist for a while now (if even for Delphi compatibility)  and it is even possible to compile the RTL/FCL using dotted units. As mentioned by MarkMLI there are some issues under certain conditions.

edit: dotted units in 3.0.0, reference manual, wiki dotted RTL

I see, thanks. I did not know this.

Sure, here we go.

Main unit (prg.pas):

Code: Pascal  [Select][+][-]

1. program prg;
2. uses myproc in 'myproc.xyz.pas'; // I initially forgot to mention that the filename also needs to include the .pas extension
3. begin myproc.myproc(1,false) end.
4.  

Library unit (myproc.xyz.pas):

Code: Pascal  [Select][+][-]

1. unit myproc.xyz;
2. interface
3. type TMyProc=procedure(a:integer;b:boolean);
4. var myproc:TMyProc;
5. implementation
6. end.
7.  

Okay, i get it now, thank you. Unfortunately this will not make it for me, as i either have to call the unit in with it's filename, or full name. Which means this is not a drop in replacement, since i don't have to do this with the original unit.

But... if it is a drop in replacement then how did they go about it then ?

Nohow, that is why i opened this topic.

You can always opt to use a 'forwarding' unit, e.g. a unit that is only referring to another unit with contains the actual procedures variables and types. But also there is the same issue of name collision.

Well, not the same; if i understood you, you meant that unit A has the original unit name and calls in unit B which has the original variable name, which is also A. This should work, but unfortunately this will mean, that i have to refer to it as B.A, because A.A does not exist and simply A will mean the unit. Which means this is also not a drop in replacement.

The wrapper function is the best solution so far.

[PascalDragon]

For now only, because that may be repaired in the future:
Even the procedure with the same name as the unit may be  invalid in the future.
As I wrote in your other thread, that may well be a bug.
So you are possibly making things worse. Rename the unit.

And i wrote in my other thread, that this is completely illogical. If the procedures' name do not collide with the units', then why do the variables'? This makes no sense. So, if this will be changed for the worse in the future - i mean something will not work, what did -  then that is hardly repairing, but rather wrecking. If something is to be repaired, that is the variable-unit name collision.

I do not consider a bug that the names of procedures and units can co-exist, but rather a feature. It seems that the environment is fully aware of this and handle it properly.

You might not consider it a bug, but the language does. The unit name is a symbol that is introduced into the whole scope of the unit, thus there must not be a variable, function, constant or type that has the same name. And fixing bugs can and does more often then not mean to forbid functionality that was possible before, because it was simply a bug.

TL;DR: this is a bug and it will be fixed.

[440bx]

<snip> The unit name is a symbol that is introduced into the whole scope of the unit, thus there must not be a variable, function, constant or type that has the same name. And fixing bugs can and does more often then not mean to forbid functionality that was possible before, because it was simply a bug.

TL;DR: this is a bug and it will be fixed.

But, shouldn't the unit name simply be the name of the scope ?, IOW, the name of the container which does _not_ imply the name is _in_ the container.  On the contrary, if the unit name is the container's name then it should NOT be itself in the container.

A bit like what happens with a record, e.g,

Code: Pascal  [Select][+][-]

1. type
2.   TRECORD = record
3.     TRECORD : integer;   { same name and it is NOT a problem (it shouldn't be)}
4.     field1  : integer;
5.   end;
6.  
7.  

The name of the scope, i.e, TRECORD is _not_ in the scope it defines which is what allows a field to use the same identifier.

Why should the rule for a unit name be any different ?

[PascalDragon]

Why should the rule for a unit name be any different ?

Because that's how Borland defined it, so ask them.

[440bx]

Why should the rule for a unit name be any different ?

Because that's how Borland defined it, so ask them.

Fair enough!

[TCH]

You might not consider it a bug, but the language does.

The language? Which one? Turbo Pascal or Free Pascal? They are not the same. There are a lot of Pascal languages which support different stuff and behave differently in a lot of cases.

Because that's how Borland defined it, so ask them.

Why would or should anyone ask Borland about a decision about Free Pascal? This is not Turbo Pascal. Free Pascal supports a lot of dialects and behaviours. If Free Pascal wants to be compatible with Borland Pascal in this matter, that will break backward compatibility with itself. And looking at this example with the way FP treats the scopes of records, it will introduce even more inconsistency. At some places the scope's name collides with items' in the scope and at another place it does not. Why would it be a bug at one place and would not be at another? Because Borland says so? That is not an argument, but a logical fallacy.

At least a flag should be introduced to make users able to switch between the Borland-compatible (pointlessly prohibitive) behaviour and the permissive one.

[440bx]

I sympathize with your position but...

Why would or should anyone ask Borland about a decision about Free Pascal? This is not Turbo Pascal. Free Pascal supports a lot of dialects and behaviours.

For the most part, FPC tries to be TP/Delphi compatible.  This eases porting code from those languages to FPC.

At least a flag should be introduced to make users able to switch between the Borland-compatible (pointlessly prohibitive) behaviour and the permissive one.

There is a valid theoretical argument for the more "permissive" implementation BUT, they usually end up allowing constructions that are very (humanly) confusing and (humanly) difficult to justify.  For instance, combine the record scope with the fact that standard names are _not_ keywords and the following is valid:

Code: Pascal  [Select][+][-]

1. type
2.   TRECORD = record
3.     TRECORD : integer;   { same name and it is NOT a problem (it shouldn't be)}
4.     field1  : integer;
5.  
6.     integer : double;    { re-use a standard name as an identifier            }
7.     hwnd    : hwnd;      { field identifier = type identifier...              }
8.   end;
9.  
10.  

In that record, there is a field that has the same name as the type it resides in _and_ in addition to that, there is a field named "integer" which is a double (it could be any other type, even integer) and, to top that, there is a field that is named the same as its type  identifier (this can also happen with parameter names and parameter types.)

More permissive isn't always desirable.  The problem is that the undesirable situations permissiveness creates are not always immediately obvious.

It's difficult to know if Borland made the choice consciously or it's just an unintended result of their implementation but, there is one important characteristic as a result and that is that, the name of the scope (which is the name of the unit) CANNOT be masked by any other identifier in the unit and THAT is a very desirable feature because when the name of the unit is used, it ALWAYS is the name of the scope, there is no room for ambiguity.

[TCH]

I understand. But if there is a valid argument for the permissive behaviour, then it is a valid case. If there is a valid case for a non-default behaviour, then it is always possible to make it optional. As i said, it would be just a flag. Disabled by default, enabled by a flag. Win-win.

[Thaddy]

Allowing a bug by a flag? Good thing that the bug will be fixed.

[TCH]

Allowing a behaviour by a flag, not a bug. For me it is a feature anyway.