|
Subject:
|
Getting the object name within a class
|
|
Posted By:
|
Koeno
|
Post Date:
|
7/1/2008 2:03:57 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
|
|
Reply By:
|
Old Pedant
|
Reply Date:
|
7/1/2008 4:34:44 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.
|
|
Reply By:
|
Old Pedant
|
Reply Date:
|
7/1/2008 4:46:48 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].
|
|
Reply By:
|
BrianWren
|
Reply Date:
|
7/1/2008 4:49:53 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.
|
|
Reply By:
|
Old Pedant
|
Reply Date:
|
7/1/2008 5:29:33 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
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???
|
|
Reply By:
|
Koeno
|
Reply Date:
|
7/15/2008 1:52:48 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.
|
