¿Debo usar String en lugar de TFilename?

Question

Al pasar los parámetros de nombre de archivo a procedimientos/funciones, debería usar TFilename o String.

Si hay una diferencia, ¿qué es y cuáles son las posibles ramificaciones si se utiliza un String?

p. Ej.

procedure TForm1.OpenFile(const AFilename : String); 
begin 
    //Open the file if it exists 
    ... 
end; 

Answer 1

creo TFilename se debe utilizar en el desarrollo de componentes debido a que IDE manera puede demostrar que es editor de la propiedad (TOpenDialog se mostrará cuando se hace clic en la elipsis en el inspector de la propiedad).

Aparte de esto, básicamente, no hay diferencia cuál usar. Recuerde que si usa TFilename debe agregar SysUtils a su cláusula de uso.

Answer 2

La única diferencia práctica entre los tipos string y TFileName en un código simple es al pasar un argumento por referencia; el código

procedure GetFileName(var FileName: TFileName); 
begin 
    FileName:= 'abcd.abc'; 
end; 

procedure TForm1.Button2Click(Sender: TObject); 
var 
    S: string; 

begin 
    GetFileName(S); 
end; 

siguiente no se compila con el error

[DCC Error] E2033 Types of actual and formal var parameters must be identical 

Answer 3

Tal vez esto es un poco demasiado obvio, pero utilizando el tipo string no se comunica nada sobre el uso previsto de una variable. Pero cuando encuentras una variable declarada como TFileName, se comunican muchos más detalles allí mismo.

El mismo principio applys a otros tipos básicos como Integer, Cardinal, Double etc. En cambio es posible que desee considerar el uso de alias para estos como TCustomerID, THashValue, TInterestRate, etc ya que estos se comunican mucho más claro lo que el uso previsto de éstos variables es

Esto mejora la reabilidad, y también permite cambiar el tipo de base cuando sea necesario, sin tener que tocar ningún código con el tipo ... simplemente recompile y listo (pero tenga cuidado con la compatibilidad binaria). .

Answer 4

Hmm, Mi fuerte preferencia es para const AFilename: String; Por la razón de que, especialmente para proyectos más grandes, si alguna vez tiene que añadir el código fuente de otro codificador, si han utilizado una gran cantidad de tipos personalizados como TCustomerID, THashValue, TInterestRate, en vez de Integer, Cardinal, Double, entonces tienes muchos de los E2033 antes mencionados para resolverlos.

Incluso un montón de delphi construidas en el código fuente no utiliza TFileName, como:

function MatchesMask(const Filename, Mask: string): Boolean; 

Por otra parte, si he definido como una variable AFileName: TFileName; entonces es obvio que es un nombre de fichero del tipo llamado & no añade cualquier legibilidad para mí, si acaso en algunos casos hace que el código sea menos legible, porque tienes que hacer clic para verificar de qué variable real se deriva.