Global variable : why the compiler don't complain about this ?

[mderie 1]

Hi,

 

I was disturbed to say the least that one can declare a global variable the same name as an existing one in another (system) unit.

IE : I encounter the case today, some funny guy declared a global like this one.

 

FormatSettings : TFormatSettings;

 

Althought the exact same line exists in SysUtils... I let you imagine what happened when debugging !

Since some units does include this funny one and the SysUtils one...

 

Any idea ? And yes I know that globals are evil :)

 

Regards.

[Rollo62 536]

Thats a situation where you could use fully qualified names, like

UnitFormats1.FormatSettings. DateSeparator

UnitFormats2.FormatSettings. DateSeparator

 

And yes, the last Uses entry wins, but if you use it may show usually some "ambiguous" name warning,

when accessing methods or fields.

 

 

Edited February 9, 2021 by Rollo62

[Der schöne Günther 316]

The same applies to type definitions. For example, there is a TBitmap in Vcl.Graphics, and a a completely different TBitmap in Winapi.Windows.

Edited February 9, 2021 by Der schöne Günther

[mderie 1]

Indeed, but it is a shame that the compiler don't emit a warning

[FPiette 383]

32 minutes ago, mderie said:

Indeed, but it is a shame that the compiler don't emit a warning

I don't think so. This is a highly desirable feature to be able to use an existing indentifier. There are rules that the compiler follow. And as @Rollo62 said, you can always use fully qualified names to designate what you want to.

 

[Guest]

 If you check the source files of RAD Studio (Delphi, for example), you will see that this happens! Therefore, it is advisable to use "name-space" for types or vars (if strictly necessary), for example:

• System.faDirectory in System.SysUtils
• TFileAttribute.faDirectory in System.IOUtils

note that "faDirectory" is used by default when you do not use "System.IOUtils" in the "Uses" and "TFileAttribute" clause to determine the enumeration where the "faDirectory" value comes from!

 

another, normally, the Global definition will be "hided"  while "local" is used... the, when "local" is out of scope, the "global" is seen.

Edited February 9, 2021 by Guest

[Fr0sT.Brutal 900]

I agree that this identifier overriding should produce a warning or a hint.

[mderie 1]

Hi,

 

<NOSTALGIA_ON>

I'm glad to rediscover a Delphi programmer community !

Back in time I was pleased to find answers through TeamB among other nice people

And finding good components on Torry's Delphi pages

</NOSTALGIA_ON>

 

Now I've quickly test C++ in respect of type redeclarations and global variable redefinitions...

Well let say that my heart beats for the later one... Delphi just takes too many shortcuts !

 

Regards

 

Edited February 10, 2021 by mderie

[David Heffernan 2345]

13 hours ago, Fr0sT.Brutal said:

I agree that this identifier overriding should produce a warning or a hint.

We've all been saying this for years and years. My old boss first said this to me 20+ years ago. We are so so so far behind. 

[Bill Meyer 337]

Although it is true that the compiler ought to catch such things, it is also true that

- Delphi declares type names like TIntArray

- we should declare like TwmIntArray

 

The more the Delphi types increase, the greater the likelihood of collisions with built-in types.

 

Naming is hard, yes, because too often names are assigned thoughtlessly.

[Guest]

1 hour ago, Bill Meyer said:

Naming is hard, yes, because too often names are assigned thoughtlessly.

no talking about... here we are talking about a "team corporative" that was replaced many many times... then, each "boss" one "vox" or would b a "Bono Vox" 

[Bill Meyer 337]

1 minute ago, emailx45 said:

no talking about... here we are talking about a "team corporative" that was replaced many many times... then, each "boss" one "vox" or would b a "Bono Vox" 

So mix or match at every turn?

[Guest]

Just now, Bill Meyer said:

So mix or match at every turn?

take a time and write to Embarcadero 'Bosses

start by Product Manager, Marcos Cantu

[Mike Torrettinni 198]

On 2/9/2021 at 3:16 PM, FPiette said:

I don't think so. This is a highly desirable feature to be able to use an existing indentifier. There are rules that the compiler follow. And as @Rollo62 said, you can always use fully qualified names to designate what you want to.

 

I like this 'feature' too. Imagine you would need to have a list of all definitions from all Delphi units (+all 3rd party code you use) to be able to create your own unique names. that would be crazy hard to find unique names.

 

What would happen if you have your own TCustomizedPanel and use it all over your project... then Delphi adds same name to their code base. Or any other 3rd party code you want to use, ads it in next update. I think the full qualified name or unit used last in uses clause if good tradeoff.

 

[Guest]

for that i like use "TmyXXX" prefix, of course, somebody can copy me now .

 

not much long this, I remember that the Marcos Cantu, "Delphi 3, The Bible", where it showed the "hierarch" of class and a little app for some like this, know all classes on Delphi.

 

[Mike Torrettinni 198]

What about enums?

Like TContactAddressType = (caBusiness, caHome, caPublic) or TmyContactAddressType= (mycaBusiness, mycaHome, mycaPublic)?

 

 

[Guest]

normally, enums should stay with its "Type"-domain for avoid this. look definition basic:

TxxxxS = (a,b,c, ....)

xxxx = set of TxxxS

 

[Mike Torrettinni 198]

Aha, Ok, makes sense.

[Lars Fosdal 1792]

Scoping can lead to some weird scenarios.
F.x.

type
  TBase = class
  private
  public
    Data: Integer;
  end;

  TChild = class(TBase)
  private
  public
    Data: string;
  end;

But, being able to "hijack" methods, simply by introducing them to the visible scope, is also kinda useful.

A set of hints would be nice, though, so that you don't do it by accident.
 

[Fr0sT.Brutal 900]

7 hours ago, Mike Torrettinni said:

What about enums?

Like TContactAddressType = (caBusiness, caHome, caPublic) or TmyContactAddressType= (mycaBusiness, mycaHome, mycaPublic)?

 

 

IMHO: First option (Classic).

Delphi is typed so most collisions will be caught by type checking.

[mderie 1]

Embarcadero should introduce namespaces !

[Remy Lebeau 1397]

11 hours ago, mderie said:

Embarcadero should introduce namespaces !

Already exists:

http://docwiki.embarcadero.com/RADStudio/en/Using_Namespaces_with_Delphi

http://docwiki.embarcadero.com/RADStudio/en/Unit_Scope_Names

[David Heffernan 2345]

6 hours ago, Remy Lebeau said:

Already exists:

http://docwiki.embarcadero.com/RADStudio/en/Using_Namespaces_with_Delphi

http://docwiki.embarcadero.com/RADStudio/en/Unit_Scope_Names

Not really namespaces as would be useful in this context. 

[mderie 1]

Come on, compare it with what exists in C++ or C# (I don't know Java enough)

Ask yourself what could be a namespace !

 

[Stefan Glienke 2002]

"Let's put dots into unit names, add some confusing matching logic for uses clauses that nobody understands and call that namespaces"

Edited March 8, 2021 by Stefan Glienke