>>I was using this technique (as required by the in-house framework), and it had a few good sides. First, the method which generates cursor names also keeps track of them, and in .destroy() just closes any open ones. Second, the names are guaranteed to be unique, so in case I need to instantiate more than one object which creates its own cursor, there will be no accidental stepping over toes/cursors of any other object.
>>
>>The downside is that you don't actually know what the alias is, so you can't easily use it in alias.field construct, but there are workarounds:
>>
>>

uValue=eval(forceext(lcAlias, "fieldname"))
>>replace fieldname with uValue2 in (lcAlias)

>
>You could just as easily have used a session object, where the code would be clean and readable and macro/name expression free.

As I said, I was using this before, when I had to. My cursors have sufficiently unique names, derived from what they are made for, so I don't have a problem with accidentally creating a new one with old one's name. When I expect such a problem, in case of, say, some recursive thing, then sys(2015) is my friend, or I constuct the cursor name from the recursion level.