Hola, OZ.
 
Si realmente estuvieras seguro de que nunca vas a tener una relación bidireccional, no lo necesitarías, pero es dificil de predecir. Aunque yo trataría de mantener esa premisa, me parece que nunca está de más poner a null las referencias a todos los objetos dependientes que tenga una clase en su Destroy.
 
En el ejemplo tuyo lo estás haciendo desde el código cliente, y si hay una relación bidireccional no funcionaría, porque al poner a null tus variables locales, te estás quedando igual con las referencias que cada objeto mantiene entre sí. ¿Se entiende? Por eso hay que hacerlo en el Destroy de cada clase.
 
Respecto al ParseLocals, no lo conozco. Mandame un link o algo así lo miro. Todo lo que tenga que ver con análisis estático es interesante porque podríamos llegar a usarlo en algunas herramientas que tenemos en danza con Andy McNeil.
 
Saludos,
   MS

 
On 11/14/06, oscar.zarate <[EMAIL PROTECTED]> wrote:
Hola muchachotes~!!!

Che, Martín, vale decir que si no hay graves problemas de diseño, no
sería necesario destriur explicitamente el Objeto?

Con respecto al ejemplo que vos decis, si:

local oCosa
oCosa = NewObject( "BlaBla" )

OtroObjeto( oCosa ) && recibe la referencia y la guarda en una propiedad

OtroObjeto = NULL
RELEASE OtroObjeto

oCosa = NULL
RELEASE oCosa

Estamos bien y si es necesario.



Con respecto a lo del tipado, "Parselocals" te avisa (en Design Time)
que no te hayas olvidado de declarar nada (es un Parser, pero un poco
limitado) por eso es que preguntaba si conocian algo mejor, pero en ese
caso debería recomendar el Parselocals.

SaludOZ
|\_/|
(.. )
- /


-----Original Message-----
From: "Martin Salias" < [EMAIL PROTECTED]>
To: "GUFA List Member"  <[email protected]>
Date: Tue, 14 Nov 2006 10:03:30 -0300
Subject: [GUFA] _vfp.LanguageOptions y object = NULL

> Hola, chicas.
>
> En realidad, las situaciones en que el Grabage Collector se mama y no
> libera
> las referencias es cuando tenés scopes cruzados.
>
> Es decir, que en el ejemplo de OZ:
>
> local oCosa
> oCosa = NewObject( "BlaBla" )
>
> * hago algo enteramente local...
> return
>
> no pasa naranja. El problema es cuando hacés:
>
> local oCosa
> oCosa = NewObject( "BlaBla" )
>
> OtroObjeto( oCosa ) && recibe la referencia y la guarda en una
> propiedad
>
> return
>
> Obviamente, al terminar de ejecutar el método el objeto no se libera,
> porque
> lo que perdió scope es oCosa, que es sólo una referencia, pero el
> reference
> count del objeto mismo bajó de 2 a 1 (hasta que no llega a cero no se
> libera). Ahora, si OtroObjeto se destruye, la cuenta daría cero y la
> instancia de BlaBla quedaría liberada ...salvo que... esa instancia de
> BlaBla tenga una referencia a su vez a OtroObjecto, porque entonces
> OtroObjeto no termina de liberarse porque tiene una referencia viva (en
> la
> instancia de BlaBla) y la instancia de BlaBla no termina de liberarse
> porque
> tiene una ferencia viva (la propiedad en OtroObjeto).
>
> Si, has creado tu memory leak, finalmente. Para evitar este problema
> (que
> afecta a casi cualquier Garbage Collector) hay dos estrategias
> principales
> (en orden de prioridad):
>
> 1 - EVITAR las referencias bidireccionales. En principio esto apesta
> desde
> el punto de vista de diseño
> 2 - Acostumbrarse a anular (this.pepe=null) las referencias en los
> destructores de las clases.
>
> ¿Se comprende?
>
> Respecto al LanguageOptions, OZ, no hay nada mucho más estricto en
> VFP. No
> hay manera de obligar realmente a que se declaren las cosas (esto sólo
> te
> chilla en el DebugOut, que no mira casi ni el loro) pero no genera nada
> más.
>
> Abrazos,
>     MS
>
>
> On 11/14/06, Christian Gutman <[EMAIL PROTECTED]> wrote:
> >
> > Hola Oscar
> >
> > A mi forma de ver...
> >
> > Fox mata la referencia, y libera el objeto, el tema es que , no
> siempre es
> > asi.
> > Fox lo limpia, pero queda en memoria
> >
> > Lo ideal, para todo tipo de variables y objetos, en fox es
> >
> > miVariableOPropiedad = null
> > Release miVariableOPropiedad
> >
> > Con eso estas forzando al engine a limpiar.
> >
> > Christian
> >
> > -----Mensaje original-----
> > De: [email protected] [mailto:[email protected]] En nombre de
> oscar.zarate
> > Enviado el: martes, 14 de noviembre de 2006 2:18
> > Para: GUFA List Member
> > Asunto: [GUFA] _vfp.LanguageOptions y object = NULL
> >
> > Como va la banda?
> >
> > Gente, alguien conoce algo tipo el "Parselocals" pero un poco más
> ...
> > mejor? :-P Algo que complemente para design time el
> _vfp.LanguageOptions
> > = 1.
> >
> >
> >
> > Por otro lado, yo recuerdo el tema de ...
> > los objetos deben ser asignados a NULL cuando queremos "matarlos"
> > ahora, con el tema del scope de los objetos, sigue siendo necesario
> > matarlos o se mueren solos?
> >
> >
> > Ej:
> > LOCAL Algo
> >
> > Algo = CREATEOBJECT("Excel.Application")
> >
> > RETURN
> >
> >
> > Este Algo, se murio, no? Solo nos que por una cuestion de "buenos
> > modales" la necesidad de hacer:
> >
> > LOCAL Algo
> >
> > Algo = CREATEOBJECT("Excel.Application")
> >
> > Algo = NULL
> >
> > RETURN
> >
> >
> > o alguno recuerda algun caso donde si o si sea necesario e
> > imprescindible matarlo?
> >
> > SaludOZ
> > |\_/|
> > (.. )
> > - /
> >
> >
> >
> > __________ Información de NOD32, revisión 1863 (20061113)
> __________
> >
> > Este mensaje ha sido analizado con  NOD32 antivirus system
> > http://www.nod32.com
> >
> >
> >
> >
>
>
> --
> Martín Salías
> www.Salias.com.ar
> Agile Alliance Member - Microsoft MVP





--
Martín Salías
www.Salias.com.ar
Agile Alliance Member - Microsoft MVP

Responder a