Opportunité d'un choix syntaxique

[tourlourou]

Bonjour,

J'ai créé un objet qui encapsule une BD SQLite. Il permet par exemple de récupérer le résultat de requêtes dans une grille :

Code :

function TMyBD.ToStringGrid(aRequest: string; aGrid: TStringGrid): integer;

Je lui ai ajouté un objet ParamSQL qui contient une requête paramétrée. Pour lui dire d'utiliser cette requête, il suffit de passer UseParamSQL (qui vaut nil) à la place de la chaîne Request :

Code :

if MyBD.ToStringGrid(UseParamSQL, MyGrid) = SQL_OK then...;

Voici donc ma question : est-il opportun (au sens de classique, intelligible, etc.) de redéfinir les fonctions sur le modèle suivant ?

Code :

function TMyBD.ToStringGrid(aGrid: TStringGrid; aRequest: string default UseParamSQL): integer;

[Andnotor]

Perso, j'aime bien utiliser des paramètres par défaut, mais il faut que ce soit le cas général utilisé la majeur partie du temps. Sinon, ça ne fait qu’alourdir la déclaration.
Certaines fois, je préfère cependant m'en passer pour conserver un ordre logique des paramètres. Par exemple une encapsulation de ShellExecute et le verbe 'open'. Le placer à la fin ne me plait pas.

Dans le cas que tu évoques et puisque la méthode s'appelle ToStringGrid, avoir aGrid en premier est tout à fait logique et si personnaliser aRequest est l'exception, une valeur par défaut est tout indiquée

ps: La valeur par défaut se déclare dans l'interface et n'a pas besoin d'être répété dans l'implémentation. On pourrait d'ailleurs ne déclarer aucun paramètre dans l'implémentation, mais ne facile pas la lecture.
Ceci est parfaitement accepté :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
interface
 
type
  TForm1 = class(TForm)
  public
    procedure ShowMsg(aText :string; aTitle :string = 'Information');
  end;
 
implementation
 
procedure TForm1.ShowMsg;
begin
  MessageBox(Handle, PChar(aText), PChar(aTitle), MB_OK);
end;

[tourlourou]

Merci beaucoup pour ton avis argumenté.

Pour la non répétition du default, OK : je codais ici dans le forum...

Par contre, qu'on puisse ne pas reprendre du tout les paramètres dans l'implémentation, tu me l'apprends !

[Dr.Who]

Je suis d'accord également, l'ordre de déclaration des paramètres doit se faire du plus "logique"/"important" au facultatif.


si on regarde quelques fonctions designée par Borland :

Code :

TryStrToInt( string , var int) boolean

il serait idiot, même si pas faux de faire :

Code :

TryStrToInt(var int, string) boolean

ou

Code :

TryStrToInt(var boolean, string) int

C'est encore plus important quand on overload, on se rend bien compte que les paramètres facultatif doivent être placés vers la fin (en prenant également en compte les types qui pourrait créer des erreur de sélecteur).

D'autant plus, qu'il faut privilégier les meilleurs registres pour les paramètres important, et laisser les paramétres moins important dans les registres "pourris".

un exemple vulgaire :

Code :

methode (A [eax], B [edx], C [esi], D [esi+0x]...): [eax]

A est forcement le paramètre le plus important. et beneficie du registre le plus rapide d’accès, le plus simple à utiliser.
c'est également vrai pour le choix d'utiliser PROCEDURE ou FUNCTION.

doit on faire :

Code :

procedure BSWAP(A: integer; out B: integer);

ou

Code :

function BSWAP(A: integer): integer;

l'exemple est un peu pourrie

mais dans la procedure on devra faire :

Code :

1
2
3
4
5
 
asm
  mov eax, edx;
  bswap edx;
end;

alors que dans la fonction on fera tout simplement :

Code :

1
2
3
4
 
asm
  bswap eax;
end;

soit une instruction de moins, donc une rapidité accrue.


dans ta fonction, l'avantage est que tout de suite on mets l'objet TStringGrid visé puis la requette (qui peu être longue si on l'écrit en dur), donc qui ne laisserai plus apparaitre à l'écran, l'objet visé.

Code :

ToStringGrid(StringGrid1, 'SELECT * FROM maTable WHERE blabla=1 AND blibli=2 AND bloblo=4 GROUP BY id SORT BY blabla ASC LIMIT 0,1000;');

c'est quand même plus sympa.

[tourlourou]

Bien vu !

Merci pour ton approche didactique en terme d'efficacité.

Grâce à vous, j'ai des arguments pour choisir

[Andnotor]

Je propose juste un petit quizz (de Noël) sur ce qu'a dit le Docteur : Quelle est la façon la plus simple de faire un Int64 à partir de deux entiers ?

La réponse est... ne rien faire !

Code :

function MakeInt64(aLow, aHigh: integer): Int64; asm end;

Explication:
Le premier paramètre est chargé dans EAX et le second dans EDX. Dans le résultat, le double-mot de poids faible se trouve dans EAX et celui de poids fort dans EDX. Aucune transformation n'est nécessaire

[Montor]

Envoyé par Andnotor

Je propose juste un petit quizz (de Noël) sur ce qu'a dit le Docteur : Quelle est la façon la plus simple de faire un Int64 à partir de deux entiers ?

La réponse est... ne rien faire !

Code :

function MakeInt64(aLow, aHigh: integer): Int64; asm end;

Explication:
Le premier paramètre est chargé dans EAX et le second dans EDX. Dans le résultat, le double-mot de poids faible se trouve dans EAX et celui de poids fort dans EDX. Aucune transformation n'est nécessaire

tu peux utiliser int64Rec,LongRec en guise de macros sans quelles introduisent aucun code supplémentaire