Discussion :

[Andnotor]

Salut à tous !

Avec deux unités contenant chacune une procédure du même nom définie en overload.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
unit Unit1;
 
interface
 
procedure Update(aXML :string); overload;
 
implementation
 
procedure Update(aXML :string);
begin
end;
 
end.

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
unit Unit2;
 
interface
 
uses SysUtils;
 
procedure Update(aFileName :TFileName); overload;
procedure DoUpdate;
 
implementation
 
uses Unit1;
 
procedure Update(aFileName :TFileName);
begin
end;
 
procedure DoUpdate;
begin
  Update('c:\temp\test.xml');
end;
 
end.

Delphi 2007 (et sans doute les versions précédentes)
L'erreur Appel surchargé ambigu est générée à la compilation. (TFileName étant de type string)

Delphi 2009
Aucune erreur à la compilation, mais l'appel à Update dans la procédure DoUpdate (Unit2) est redirigé sur la procédure Update de la Unit1 . Alors qu'on s'attendrait plutôt à ce que la procédure dans l'unité courante soit prioritaire ou qu'au minimum l'inclusion de la Unit1 dans l'interface ou l'implémentation permette une différenciation.

Pour que l'appel soit correct:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Unit2.Update('c:\temp\test.xml');
//ou
Update(TFileName('c:\temp\test.xml'));

Bien sûr, ceci fonctionne correctement:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
procedure DoUpdate;
var
  FileName :TFileName;
begin
  FileName := 'c:\temp\test.xml';
  Update(FileName);
end;

A bon entendeur...

[Paul TOTH]

bon non, le chaine constante n'est pas un TFileName, c'est donc logique que la version "string" soit invoquée

ça t'apprendra à jouer avec les overload !

[Andnotor]

Ok, pertinent

Mais alors pourquoi est-ce ambigu sous D2007 .

[ShaiLeTroll]

il n'y aurait pas non plus une histoire de String Ansi et Unicode en Delphi2009 qui facilite la résolution ?

TFileName est-il le même dans le deux Delphi donc String (Ansi 2007, UniCode 2009)

Sinon, ils ont du renforcé le compilateur sur la gestion de informations de type, il ne doit plus considérer le TFileName comme une simple string mais comme un type à part entière ...

faudrait essayer la même chose avec un Double et un TDateTime par exemple ...

[Andnotor]

C'est un type distinct, comme précédemment.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

TFileName = type string;

Mais les génériques sont passés par là. Certainement une cause à effet .

[Paul TOTH]

Ok, pertinent

Mais alors pourquoi est-ce ambigu sous D2007 .

parce que ton code l'est

je pense que c'est en effet une faiblesse du compilateur qui a donc été ensuite corrigée...mais je trouve personnellement que les overload sont casse gueule car (en admettant que le compilateur ne se trompe pas) tu ne sais plus forcément ce que tu fais

EDIT: d'ailleurs je ne savais pas que l'overload fonctionnait entre deux unités distinctes...mais je trouve ça d'autant plus casse gueule ! Imagine que tu ne soit pas l'auteur de la version TFileName et que tu penses invoquer la version string en lui passant un TOpenDialog.FileName ! bonjour les dégâts

[Andnotor]

N'ait crainte, je reprenais simplement une ancienne unité et me suis retrouvé avec ce "conflit" de nom. Le but n'était pas d'éparpiller la gestion dans plusieurs unités . (J'ai d'ores et déjà renommé les nouvelles procédures)

Ce qui est casse-gueule est surtout que le type distinct TFileName puisse être assimilé à une string lorsque ça arrange le compilateur .

Edit:

EDIT: d'ailleurs je ne savais pas que l'overload fonctionnait entre deux unités distinctes...mais je trouve ça d'autant plus casse gueule ! Imagine que tu ne soit pas l'auteur de la version TFileName et que tu penses invoquer la version string en lui passant un TOpenDialog.FileName ! bonjour les dégâts

Je l'ai appris à mes dépends aussi

[Franck SORIANO]

...mais je trouve personnellement que les overload sont casse gueule car (en admettant que le compilateur ne se trompe pas) tu ne sais plus forcément ce que tu fais

Ca dépend comment on utilise l'overload. Personnellement je ne l'utilise qu'avec un nombre de paramètres différents. Sinon avec les convertions implicites (et certain langages vont beaucoup plus loin que Delphi de ce côté là) bonjour les déjats en effet.

Ce qui est casse-gueule est surtout que le type distinct TFileName puisse être assimilé à une string lorsque ça arrange le compilateur .

C'est ce qui arrive avec les conversions implicites.
Moi c'est plutôt le fait que maintenant ça ne soient plus ambigue qui me dérrange.