Of course you can do that, but what's the value????
As I noted, if you pass that reference off to some subroutine, etc., why does where it was created matter?
In fact, I could easily see creating an instance in a method of some class, returning the reference from the method, and then the method (and maybe even the object that contained that method) go out of scope and are garbage collected and you still have this created object floating around with the name of something that no longer exists.
Can you think of a few cases (or even one case) where knowing WHAT created an object would be important?
The best I can come up with be something like this: You create a visual object [e.g., a button] within a nother visual object [e.g., a row in a datagrid] and you want to be able to get the container [the row] so you can perform operations on other items in the same container [same row].
Makes sense. But then the *NAME* of the object that created you is WORTHLESS! What you really need is a *REFERENCE* to the object that created you. You could care less what its name is (or even if it has a name).
So, yeah, I can see doing
Dim children(20) AS DisplayableObject
Sub makeButton( )
children(x) = New Button( "Push me", "red", Me )
[horrible coding, but you get the idea] passing in ME so the button can find its parent. But why would you pass in ME.NAME, even if ROW had a NAME field???