cómo evitar de forma segura el error de Delphi: "los tipos de parámetros formales y reales deben ser idénticos"

Question

Necesito una forma de escribir un procedimiento genérico para actuar sobre un tipo de objeto o cualquiera de sus descendientes.

Mi primer intento fue declarar

procedure TotalDestroy(var obj:TMyObject); 

pero cuando se utiliza con un objeto descendiente

type TMyNewerObject = class(TMyObject); 
var someNewerObject: TMyNewerObject; 

TotalDestroy(someNewerObject); 

me sale el error infame "tipos de parámetros formales y reales deben ser idénticos"

Entonces, mientras luchaba por encontrar una solución, miré el código fuente del procedimiento Delphi system FreeAndNil. Y me encontré con esta declaración impresionante, junto con este sorprendente comentario

{ FreeAndNil frees the given TObject instance and 
    sets the variable reference to nil. 
    Be careful to only pass TObjects to this routine. } 

procedure FreeAndNil(var Obj); 

Evita el tipo de comprobación de errores, pero utiliza ninguna red de seguridad.

Mi pregunta es ... ¿hay alguna manera segura de verificar el tipo de un parámetro var sin tipo?

o en otras palabras, ¿puedes mejorar este código fuente Delphi para que la advertencia no sea necesaria?

procedure FreeAndNil(var Obj); 
var 
    Temp: TObject; 
begin 
    Temp := TObject(Obj); 
    Pointer(Obj) := nil; 
    Temp.Free; 
end; 

Answer 1

He escrito sobre esto antes, usando un ejemplo muy similar a Lasse's:

• Delphi Q&A: Why must the types of actual and formal var parameters be identical?

A menos que usted está escribiendo una instrucción de asignación a cambio el valor de la entrada el parámetro en sí, y no solo una de sus propiedades, no debe pasar un parámetro por referencia en primer lugar.

Si es escribiendo una instrucción de asignación para cambiar el valor del parámetro, entonces el mensaje del compilador realmente es verdadero, y debe prestarle atención.

Una razón para tener que eludir el error es cuando está escribiendo una función como TApplication.CreateForm. Su trabajo es cambiar el valor del parámetro de entrada, y el tipo del nuevo valor varía y no se puede determinar en tiempo de compilación. Si está escribiendo esa función, entonces su única opción con Delphi es usar un parámetro untyped var, y luego hay una carga adicional tanto para el que llama como para el receptor para asegurarse de que todo vaya bien. La persona que llama necesita asegurarse de que pasa una variable que es capaz de contener valores de cualquier tipo que la función ponga en ella, y la función necesita asegurarse de que almacena un valor de un tipo compatible con lo que solicitó la persona que llamó.

En el caso de CreateForm, la persona que llama pasa un literal de referencia de clase y una variable de ese tipo de clase. La función instancia la clase y almacena la referencia en la variable.

No tengo muy buena opinión de CreateForm o FreeAndNil, en gran parte debido a la forma en que sus parámetros sin tipo sacrifican la seguridad del tipo a cambio de una conveniencia comparativamente pequeña. No ha demostrado la implementación de su función TotalDestroy, pero sospecho que su parámetro var finalmente proporcionará la misma utilidad baja que en esas otras dos funciones. Ver mis artículos sobre ambos:

• When should I use FreeAndNil?
• Why shouldn't I call Application.CreateForm?

Answer 2

Vamos a examinar lo que quieres hacer.

Quiere llamar a un método que toma X, pasando un objeto de tipo Y, donde Y es un descendiente de X. El inconveniente, el parámetro es un parámetro "var".

Analicemos qué podría hacer si eso fuera posible.

type 
    TBase = class 
    end; 
    TDescendant = class(TBase) 
    end; 

procedure Fiddle(var x: TBase); 
begin 
    x := TDescendant.Create; 
end; 

type 
    TOtherDescendant = class(TBase) 
    end; 

var a: TOtherDescendant; 
a := TOtherDescendant.Create; 
Fiddle(a); 

Uh-oh, ahora a ya no contiene una instancia de TOtherDescendant, que contiene una instancia de TDescendant. Eso probablemente sea una sorpresa para el código que sigue a la llamada.

Usted no sólo debe tener en cuenta lo que la intención que ver con la sintaxis que se propone, pero efectivamente lo que podría ver con la sintaxis.

Deberías leer la excelente publicación de Eric Lipperts en el blog sobre problemas similares en .NET, que se encuentra aquí: Why do ref and out parameters not allow type variation?.

Answer 3

Además de lo que escribió Lasse, que es bastante correcto, la mayoría de las veces no desea pasar un objeto a var parámetro de todos modos.

Un objeto es un tipo de referencia. Lo que ves como el objeto es en realidad una referencia a él. Solo querría pasar un objeto referencia a un parámetro var si quiere cambiar su objeto por un nuevo objeto. Si solo desea poder modificar los miembros del objeto, puede hacerlo simplemente pasándolo a un parámetro normal. Haga que la llamada al método tome un parámetro TMyObject en lugar de un parámetro var TMyObject y debería funcionar.

Por supuesto, si realmente está reemplazando el objeto, entonces no dude en ignorar todo esto, y vea la respuesta de Lasse.