FreeAndNil VS Free

[rgstuamigo]

Empezado por roman

Pues no. Porque en realidad, esto:

Código Delphi [-]
procedure TForm2.FormClose(Sender: TObject; var Action: TCloseAction);
begin
Action:=caFree;
Form2:=nil;
end;

es una mala práctica. Una clase no debería hacer referencia a una instancia en particular. Yo sé que esto es muy común pero no debería hacerse de esta manera.

De entrada, no debería usarse la variable Form2 que el IDE crea en automático por la simple razón de que no es bueno usar variables globales. Si el formulario principal requiere una instancia de Form2 y necesita tenerla reservada, entonces se declara una variable de tipo TForm2 (o, mejor, de tipo TForm) como campo privado.

// Saludos

Estoy de acuerdo con lo que dices supongo que te estás refiriendo a que el código quede más limpio, es decir, no hacer que en mi clase haga refencias aun objeto en cuestion, pero la cuestion es que: dime ¿Cómo harias para que al momento de destruir mi formulario con Action:=caFree, hagas que dicho formulario apunte a nulo (nil)?

[roman]

Empezado por rgstuamigo

¿Cómo harias para que al momento de destruir mi formulario con Action:=caFree, hagas que dicho formulario apunte a nulo (nil)?

Por ejemplo...

// Saludos

[rgstuamigo]

Empezado por roman

Por ejemplo...

// Saludos

Pues creo no me he explicado bien..... bueno el ejemplo que pones en ese hilo hace uso de los métodos FreeNotification y Notification que son válido si se quiere hacer de cualquier forma,yo diría que es otra forma de hacer lo mismo que hice en el post 26,claro de una forma un poco más elegante , si te dás cuenta igualmente estás haciendo uso de un variable privada, fuera de la clase a la que pertenece tu variable "ChildForm" es decir mi pregunta era que dentro de la clase "TChildForm"(siguiendo tu ejemplo) sin salir fuera de ella y sin hacer uso de una variable, llamese ésta global o privada puedas lograr que cualquier objeto instanciado que pertenesca a la clase "TChildForm" al momento de destruirse se ponga nulo (nil). Es decir, el formulario donde se está creando (instaciando) objeto de la clase "TChildForm" no tiene por que hacer el trabajo de poner a dichos objetos en nulo, cada objeto al momento de destruirse ya, él por si mismo debería ponerse en nulo. ¿me entiendes?, es por eso que pensé que sería bueno contar con un método ReleaseAndNil, a lo cual te opusiste.
Saludos...

[roman]

Empezado por rgstuamigo

cada objeto al momento de destruirse ya, él por si mismo debería ponerse en nulo. ¿me entiendes?

Te entiendo, pero no estoy de acuerdo por dos razones:

1. Quien se pone nulo no es el objeto sino una referencia al objeto. Diferencia sutil pero importante. Puedes tener múltiples referencias a un mismo objeto, así que, ¿cuál de ellas es la que se pondría en nulo al momento de destruir el objeto? Eso es algo que puede decidir quien creó al objeto, mas no el objeto en sí.

2. Como no sea una suerte de patrón singleton, por lo general puedes tener varias instancias de una misma clase. Aún en el caso de formularios que en un determinado contexto quieres abrir una sola vez. Entonces, ¿a cuál de estas instancias se debe referir el destructor de la clase?

Por otra parte,

Empezado por rgstuamigo

yo diría que es otra forma de hacer lo mismo que hice en el post 26,claro de una forma un poco más elegante , si te dás cuenta igualmente estás haciendo uso de un variable privada, fuera de la clase

no es que sea más elegante, sino que es fundamentalmente distinta. Mi variable privada se anula fuera de la clase y lo hace quien creo la instancia.


Yo diría, en una especie de resumen, que las referencias a un objeto son entidades ajenas a la clase del objeto (y al objeto mismo).

// Saludos

[rgstuamigo]

Empezado por roman

Te entiendo, pero no estoy de acuerdo por dos razones:

1. Quien se pone nulo no es el objeto sino una referencia al objeto.
...
2. Como no sea una suerte de patrón singleton, por lo general puedes tener varias instancias de una misma clase.

Bueno eso ya sabemos amigo roman y eso no está en discucion... no mezclemos las cosas

Empezado por roman

Por otra parte,

...
no es que sea más elegante, sino que es fundamentalmente distinta. Mi variable privada se anula fuera de la clase y lo hace quien creo la instancia.


Yo diría, en una especie de resumen, que las referencias a un objeto son entidades ajenas a la clase del objeto (y al objeto mismo).

Haber... tú mismo criticaste el hecho de que se usara la variable global que genera Delphi a crear un formualrio, pero si analizamos tu solucion pues basicamente hace lo mismo, claro ahora ya no es una variable Global sino privada, pero de igual manera se la está usando practicamente para hacer lo mismo, pero mejor me explico con un ejemplo siguiendo tu propia solución:
Si por ejemplo instanciaramos un objeto de la clase "TChildForm" de la siguiente forma:

Código Delphi [-]
if otroForm = nil then// OtroForm es otra instacia diferente de ChildForm
 begin
   otroForm := TChildForm.Create(Self);
   otroForm.FreeNotification(Self);
 end;
otroForm.Show;

Para que tu solucion funcione tambien con "OtroForm" deberiamos modifcar el método Notification de la siguiente forma:

Código Delphi [-]
procedure TParentForm.Notification(AComponent: TComponent; Operation: TOperation);
begin
  inherited;

  if (AComponent = ChildForm) and (Operation := opRemove) then
    ChildForm := nil;
//lineas aumentadas
 if (AComponent = OtroForm) and (Operation := opRemove) then
    OtroForm := nil;
{ohora te podas imaginar que ocurre si seguimos creando mas instancias con diferentes referencias..  }
end;

Eso quiere decir que por cada nueva referencia tengo que aumentar código al método Notification..y eso no es ideal amigo seamos realista.
En otras palabras estamos restringidos a crear un objeto solo atraves de la variable "ChildForm", si quisieramos que la cosa siga funcionando y evitar agregar más código; y..pues es practicamente lo mismo que hacer uso de la varible global que gerera delphi, asi que por ese lado no hay diferencia.
Bueno... para no hacerla muy larga la cuestion...pues voy a volver a hacer la pregunta:
¿Es posible implementar una solucion que esté dentro de la misma clase sin utilizar alguna variable en sí? es decir al momento de Destruir(Action:=caFree el Objeto hacer que la referencia del objeto sea nula(nil)?? ¿será posible eso?

[roman]

Dices esto:

Empezado por rgstuamigo

Bueno eso ya sabemos amigo roman y eso no
está en discucion... no mezclemos las cosas

y sin embargo preguntas esto

Empezado por rgstuamigo

¿Es posible implementar una solucion que esté dentro de la misma clase sin utilizar alguna variable en sí? es decir al momento de Destruir(Action:=caFree el Objeto hacer que la referencia del objeto sea nula(nil)?? ¿será posible eso?

¿Cuál objeto? ¿Cuál de todos los objetos que pueden crearse de una clase quieres que se ponga en nulo? Pero, sobre todo, ¿cuál de todas las referencias al objeto quieres que se ponga nula? Pues, aunque lo desestimas, es una diferencia importante que, por tu argumentación, parece que no tienes clara.

// Saludos

[rgstuamigo]

Empezado por roman

..
¿Cuál objeto? ¿Cuál de todos los objetos que pueden crearse de una clase quieres que se ponga en nulo? Pero, sobre todo, ¿cuál de todas las referencias al objeto quieres que se ponga nula? Pues, aunque lo desestimas, es una diferencia importante que, por tu argumentación, parece que no tienes clara.

// Saludos

Bueno... a lo que me refiero roman es a que si es posible que cualquier referencia, al destruirse el objeto al que apunta, se pueda poner en nula, pero lo que se quiere es que la solucion para eso esté dentro de la misma clase no fuera de ella... ¿Es posible hacerlo o no?
Por favor responde la pregunta...sin vueltas...