Getting the object name within a class

Koeno · July 1st, 2008, 02:03 PM

From within a class I'd like to get the name of the object wich is using this class. At first I thought there's a way to do this by the system.reflection namespace, but it seems like that namespace only provides information from the class itself, like classname and methodnames.

Anybody knows how I can get the name of an object from within the object (class) itself?

Example:
class cTest
  sub New
  end sub

  function GetMyName as string
     'code here for returning the name of the object wich uses this class
  end function
end class

dim oTest as new cTest

messagebox.show ("Hi, my name is " & oTest.GetMyName)

Hope I explained myself well here. Many thanks in advance,

koen

Old Pedant · July 1st, 2008, 04:34 PM

Objects don't have names.

Oh, if the class they are an instance of have, say, a
     Public Name As String
field, then I guess you could say the that object contains a Name value.

I *THINK* what you mean is that you want the name of the *VARIABLE* that references the class????

So in your example
    dim oTest as new cTest
    messagebox.show ("Hi, my name is " & oTest.GetMyName)
you want to have it actually display
    Hi, my name is oTest????

First of all, what's to prevent your code from doing
    Dim zamboni As cTest
    ...
    zamboni = oTest

Now you have *TWO* variables referencing the *SAME OBJECT*.

Same thing if you had a method
    Sub foo( framitz As cTest )
         ... code ...
    End Sub
and then you did
    foo( oText )

framitz is yet *another* reference to the ONE AND ONLY cTest object that you have created!

There's no such thing as a single "owner" of an object. So of course there's no reason to be able to find the name of the "owner" when there might be 3 or 10 or 100 or 10,000 variables all referencing the SAME OBJECCT!

My guess is that you have assumed that when you do
    dim oTest as new cTest
    Dim zamboni As cTest
    zamboni = oTest
that you would have two separate objects. But nothing could be further from the truth.

If you don't use the NEW operator, you can't GET a new object. You can only get a REFERENCE to an existing object.

So...sorry...but your question is a non sequitir.

Old Pedant · July 1st, 2008, 04:46 PM

Incidentally...

In general, variable names do *NOT* appear in compiled code!

So when you do
Dim oTest As New cTest
almost surely when the code is running, the name "oTest" is nowhere to be found.

It makes sense: What's the point in knowing it??? It's just extra overhead to keep around.

[This doesn't apply to code compiled for debugging, where information such as variable names is needed for the debugger, so that it can display and use the variable name, instead of just "address 0x88771199" which is how the variable might appear in fully compiled code [except of course in non-human-readable form].

BrianWren · July 1st, 2008, 04:49 PM

You really will reduce your headache count by adding a property to the class that gets filled in when the class is instantiated, where you actually fill in the name of the object creating it. Though it would not be automatic (and making something automatic is a lot of fun), it would be flexible. You can put Me.Name if you are instantiating within a class (including a form), hard-code it, or maybe use reflection to get the name of the running object/code/function/module that is instantiating the class, and use that value in the constructor.

Old Pedant · July 1st, 2008, 05:29 PM

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

Code:

     Class Row 
         Dim children(20) AS DisplayableObject
         Sub makeButton( )
             children(x) = New Button( "Push me", "red", Me )
         End Sub
         ...

[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???

Koeno · July 15th, 2008, 01:52 PM

both Brian and Old Pedant thanks a lot for your expert views on thisone. it helped a lot. What I want to do obviously doesn't make much sense. So I will try other ways.