several ways to accomplish this, but nothing really stable.
I'd probably newobj in a special proc, hook to _screen and not into a variable and mirror that variable path in the object after creation.
Easy way to leak memory and grow hanging references, but you know enough to prevent this on destruction time.

Another might be to get a name and then a local ref with constant name via program(-x). Less risk of hanging references, but program(-x) is often unfriendly in maintainance, as more functionality is added ;-)))

Going on a limb clearvoyancing your plans, I'd work with a special SQL_Tablecontainer, where each newobjected class would land in an addpropertied() name under control at newobject time ;-))

Define Class cnt_Sql as custom

procedure NewSQL(tcRefName)
  local loRef
  loRef = NewObject('SqlTable','SQL.vcx')
  loRef.CallName = m.tcRefName
  this.AddProperty(m.tcRefName, loRef)


EndDefine

Either cnt_SQL is a constant singleton, or have a defined object path in the app
.Add/.NewObject might be easier on destruction time, set the name via
store m.tcRefName to "This." + m.tcRefName + ".CallName"

HTH

thomas



>I have a moment of brain shortage, right now I can't see the forest for all the trees. Is it possible from within an object to know what is the name it's instantiated as? Given this code
>
>

>loCountries = NewObject('SqlTable','SQL.vcx')

>
>In this case I want the class SqlTable to understand that it's instantiated as loCountries. I am building a rather complicated generic class to work with SQL tables. My idea is that if I call the object for instance loCountries, my class can be smart enough to know that I want it to connect to the SQL table called Countries.