Dragan,

>In production sure no need for that, but in development his way (i.e. a release of a reference releases object itself) would be probably easier to debug. Any stranded reference would become .null. but would do no harm. Hanging references would either be .null. if the object is released while it's still needed, or they'd sleep harmlessly until QUIT. Trying out such a thing, we'd simply run across a .null. reference, and start looking for the idiot who released the object prematurely.

I don't think that would make it any easier to debug at all. Trying to find who killed the object could be a daunting task. Plus all the method errors that would ensue trying to use a nulled reference would complicate life to the point that a CLEAR ALL is the only out. Also what is someone coded release this.oReference?

>A real thing would be to have, of course, the this.references[] collection, and it should, IMO, keep the _names_ of the variables/members/properties which are referencing it. I can imagine nice chaos if this.references[] kept references. Nice recursive chaos :).

Yeah they'd have to be pseudo references for sure, ie don't get reference counted. But it would be hard to do, because at createobject() time I don't even think the memvar that will hold the returned value exists yet? That might be worth a test: goObject = createobject() does goObject even exist at .Init() time?

>For as long as this thread continues, I'm coming to the conclusion that this.references[] is not simply protected from programmer's touch, but that it simply doesn't exist. The only backlink from the object to the variables referencing it is the reference count. The object itself is happily unaware of any variables/others referencing it. Maybe some insider may shed some light on this matter.

I can't say for sure, but I seriously doubt there is an internal References[] collection in there already.