Getting class instance names via reflection

[Guest]

I would like to get the class INSTANCE name (not type name) of an
'object'.

I can get the object (l_obj_ref.GetType()) and then get the
(l_obj_typ.Name) for the class name.

I there any way of getting 'l_Fred_my_ins' out of the following.

....
My_cls l_Fred_my_ins = new My_cls();

Type l_rfl_trg_typ = l_my_ins.GetType();

string l_ins_nam_str = l_rfl_trg_typ.GetClassInstanceName();
....

I would like to 'l_ins_nam_str' instance names for debugging purposes (for
now).

So I want to print out the instance names (of pattern instantiations).

Thanks much for any response.

Shawnk

PS. I'm looking for the syntactic corollary to
'l_whatever.GetClassInstanceName'.

 

[Vijay]

Not sure if you saw this thread... or it will help.. read through it.. , I
am out now...will try to help when I get back..

http://groups.google.com/group/comp...+via+reflection&rnum=5&hl=en#e2cc2ccf047d2063

VJ

 

[Mattias Sjögren]

I there any way of getting 'l_Fred_my_ins' out of the following.

If it's a field in a type, you can use reflection on that type to find
the field name. Of course many fields may refer to the same object so
you're not guaranteed to find a correct match.

If it's a local variable it's not possible. Local variable names are
lost during compilation and only available in debug symbols.


Mattias

 

[Jon Skeet [C# MVP]]

I would like to get the class INSTANCE name (not type name) of an
'object'.

There's no such thing. For instance:

object x = new object();
object y = x;

There's only one object involved - what's its name?

 

[Vijay]

Ok, that makes more sense..., this can't be done..., basically you are
trying to get variable names for a Class....

VJ

 

[Bruce Wood]

Or, stated another way, instances to not have intrinsic names.

Variables have names, but variables cannot contain class instances,
only references to them. So a given variable of the class type in
question has a name, but that variable may refer to a class instance
(an "object") of may refer to nothing at all ("null").

Furthermore variables have names only for the benefit of the
programmer. The CLR doesn't need these names, so they are eliminated in
the compilation process. The only place that such names are available
is in the .pdb debug information, should the assembly be compiled with
debugging enabled.

For a release compilation, there are no variable names retained, and
even the variables themselves may not be retained. In Jon's example,
the variable "x" may be completely eliminated in the compile phase or
the JIT phase, leaving no evidence of it whatsoever in the final
code... if the compiler / JITter determines that the same effect can be
had without the variable in question.

So, no... you can't get the name of an object instance, because it
isn't clear what that means at run time.

 

[Guest]

object x = new object();
object y = x;

There are two instance names that both
point to the same instance in memory.

The instance names are x,y.
The instance names exist prior to any compilation.
In fact, they never need to be compiled in order to exist.

The class name of x is 'object' and the class name of y is object.

x and y both have the same type and, thus, class name.
x and y are both 'instance names' which are labels for an instance
of type 'object' in memory. The runtime instance (location in memory)
is a different semantic (meaning, thing) from the code (text in the program)
text 'x' and 'y'.

What semantic term to label 'x' and 'y' do you use (your semantic english
term,
not the language computing term such as token, lexeme)?

 

[Guest]

Mattias,

I can get the 'type name' of the field via the Type.Name property
which I've already done.

Could you give me the API call/property/ect that will return the instance
name?

Shawnk

 

[Guest]

Thats what I thought after doing some reflection coding and going through the
docs but I wanted to verify it here.

Shawnk

Ok, that makes more sense..., this can't be done..., basically you are
trying to get variable names for a Class....

VJ

 

[Guest]

Bruce,

Thank you for your excellent and articulate reply.

That was my understanding but I wanted to be sure.

In the spirit of Jon Skeets response what (single) semantic engllish term
do you tag the following code text phenomena with (not type names BTW).

Variable name
Method name
Propery name
.....

The spectrum of items above is all member types for classes and (next level
up) assembly types such as modules, attributes, ect.

The term I use is 'instance names' for a single english semantic label (vs
computing or C# specific semantics).

As you so put it so well ... Instance names are for the benefit of the
programmer (and of course for the code to tell the compiler what to output).

Thanks again for such an articulate and though response.

Shawnk

PS. Its OK so say you don't have a single english semantic term for instance
names (for the lack of a better word ....).

PPS. The name of a C# method, for example, is an 'C# method instance name'.
Thus, dropping the 'method' we have 'instance name' for short.

 

[Guest]

Re-reading this we have;

1. Instance name (inclusive of runtime/code, determined by surrounding
context)
2. Runtime instance name
3. Code (text) instance name

So, Jon, what do you call the above three items in your day to day
'development room' conversations

Shawnk

 

[Jon Skeet [C# MVP]]

Re-reading this we have;

1. Instance name (inclusive of runtime/code, determined by surrounding
context)
2. Runtime instance name
3. Code (text) instance name

So, Jon, what do you call the above three items in your day to day
'development room' conversations

Well, objects themselves don't have names. Variables have names
(whether they are local variables or fields), methods have names, types
have names and properties have names. I tend to call each of those by
its name.

 

[Jon Skeet [C# MVP]]

There are two instance names that both
point to the same instance in memory.

Neither of those names are names of an instance, however, so calling
them "instance names" is misleading. They are variables - the *variable
names* are x and y.

The instance names are x,y.
The instance names exist prior to any compilation.
In fact, they never need to be compiled in order to exist.

The class name of x is 'object' and the class name of y is object.

Well, the type of variable x is object.

x and y both have the same type and, thus, class name.
x and y are both 'instance names' which are labels for an instance
of type 'object' in memory. The runtime instance (location in memory)
is a different semantic (meaning, thing) from the code (text in the program)
text 'x' and 'y'.

What semantic term to label 'x' and 'y' do you use (your semantic english
term, not the language computing term such as token, lexeme)?

Variables.

 

[Jon Skeet [C# MVP]]

That was my understanding but I wanted to be sure.

In the spirit of Jon Skeets response what (single) semantic engllish term
do you tag the following code text phenomena with (not type names BTW).

Variable name
Method name
Propery name
....

If the variable in question is a field (i.e. not a local variable) then
those are all members - "member name" can describe a property, field,
method, nested type etc.

The spectrum of items above is all member types for classes and (next level
up) assembly types such as modules, attributes, ect.

The term I use is 'instance names' for a single english semantic label (vs
computing or C# specific semantics).

But the trouble is, they aren't names of instances.

PS. Its OK so say you don't have a single english semantic term for instance
names (for the lack of a better word ....).

PPS. The name of a C# method, for example, is an 'C# method instance name'.
Thus, dropping the 'method' we have 'instance name' for short.

But that's dropping the most informative part, leaving something which
is misleading. An "instance name" should logically be the name of an
instance - but a method *isn't* an instance. It's like dropping the
"library" part of "class library name" to get "class name" even though
you're not actually talking about the name of a class.

 

[Bruce Wood]

Take care with the distinction between "variable" and "field". In the
following code sample,

public class Example
{
private int fieldA;

public void MethodB()
{
string variableC;
}

public int PropertyD { get { return this.fieldA; }}
}

"fieldA" is a field (which has a name), while "variableC" is a
variable, which has a name only at compile time, and may not even exist
at run time.

In the list you gave, "variable name" is the only one that is a
transient phenomenon. The other two are permanent aspects of a class.
All of the following: field, property, method, event, and constructor
(which is a special kind of method) form part of the signature of a
class (if they are public, protected, internal, or protected internal)
or could do if their access were changed (if they are private). The
overarching term that encompasses all of them is "member" (this from
MS).

"Variable," on the other hand, is quite a different animal. It is
transient both in time (it exists only during a call to the method that
declares it) and in program state (it may be eliminated at runtime at
the discretion of the compiler or the JITter).

Reflection allows you to get information about members: fields,
properties, methods, events, and constructors. It doesn't tell you
anything about variables, because they're fundamentally different
beasties. As far as a running program is concerned, then, members _do_
have names. Variables, however, do not.

 

[Stefan]

Hi,

Check out this article on Reflection:

http://www.developersdex.com/gurus/articles/739.asp

Stefan
C# GURU

"You always have to look beyond the horizon and can never be complacent
-- God forbid we become complacent." Jozef Straus

 

[Guest]

Jon,

Since my original post was answered I'll repost the semantic issues in a
separate post (to follow this one).

My interest in the semantic issues you've raised stems from the following
scenario.

Imagine you are the lead designer for a 'program by voice' product. A key
user segment of the product is brilliant people with physical handicaps
who can not type but have a clear speaking voice.

They 'write code' verbally in English and require synchronization of logical
semantic terms across verbal, written and compiled (runtime) logical
domains.

The semantic synchronization (across the three logical domains) is
critical to product functionality.

Any currently existing semantic holes (missing terminology), logical
collisions and poorly defined meanings must be resolved.

Since I have a strong interest in the above semantics I am deeply
appreciative of your (and Bruce Woods) input regarding the 'instance
name' term.

Since I am aware of others in the C# community with a similar semantic
interest I will repost this from a more focused approach.

As always thank for your excellent and though responses.
You, and Bruce Wood, are a great resource

Shawnk

 

[Guest]

Bruce,

Thanks again. Please see close out reponse to Jon Skeet as it applies to
your excellent observations.

Shawnk

 

[Jon Skeet [C# MVP]]

Take care with the distinction between "variable" and "field". In the
following code sample,

public class Example
{
private int fieldA;

public void MethodB()
{
string variableC;
}

public int PropertyD { get { return this.fieldA; }}
}

"fieldA" is a field (which has a name), while "variableC" is a
variable, which has a name only at compile time, and may not even exist
at run time.

fieldA is also a variable though. From the 1.1 spec:

<quote>
C# defines seven categories of variables: static variables, instance
variables, array elements, value parameters, reference parameters,
output parameters, and local variables.
</quote>

 

[Jon Skeet [C# MVP]]

Any currently existing semantic holes (missing terminology), logical
collisions and poorly defined meanings must be resolved.

Could you give an example of a semantic hole? I don't know of any -
it's just that the terminology you've been using isn't that of the
spec.

Now, there are lots of people who use terms incorrectly (such as
stating that C# "passes objects by reference" when it does no such
thing) but that's a matter of education, not a matter of specification
inaccuracy or poor definition.