Getting class instance names via reflection

[Shawnk]

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....cc2ccf047d2063

VJ

"Shawnk" <Sh****@discussions.microsoft.com> wrote in message
news:64**********************************@microsof t.com...

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'.

[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

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Jon Skeet [C# MVP]]

Shawnk <Sh****@discussions.microsoft.com> wrote:

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?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Vijay]

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

VJ

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Shawnk <Sh****@discussions.microsoft.com> wrote:

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?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

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

[Shawnk]

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

[Shawnk]

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

"Mattias Sjögren" wrote:

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

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Shawnk]

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

Shawnk

"Vijay" wrote:

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

VJ

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Shawnk <Sh****@discussions.microsoft.com> wrote:

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?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Shawnk]

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.

"Bruce Wood" wrote:

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.

[Shawnk]

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

"Shawnk" wrote:

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

[Jon Skeet [C# MVP]]

Shawnk <Sh****@discussions.microsoft.com> wrote:

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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Shawnk <Sh****@discussions.microsoft.com> wrote:

object x = new object();
object y = x;
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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Shawnk <Sh****@discussions.microsoft.com> wrote:

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[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

*** Sent via Developersdex http://www.developersdex.com ***

[Shawnk]

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

[Shawnk]

Bruce,

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

Shawnk

[Jon Skeet [C# MVP]]

Bruce Wood <br*******@canada.com> wrote:

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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Shawnk <Sh****@discussions.microsoft.com> wrote:

<snip>

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Shawnk]

"Jon Skeet [C# MVP]" wrote:

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.

Jon,

I meet very few people with your insight and unstoppable energy. The
community is lucky to have you.

I have (already partially written) two posts that answer this since its
fundamental nature is beyond C# but very pertinent to it (semantically).
The two, a short humorous and long serious post deal with semantic
synchronization. I wasn't sure if I was going to post them (I hate to
waste peoples time).

But since this aspect (architectural and design semantics of C#) is of
interest I rewrote your code (x and y code) in a (somewhat) humorous
response to your question. The short humorous post pays homage to you
and, I trust, brings out the 'instance name' validity as a fundamental
perspective of english (human language) semantics.

Here is the short temporary 'answer' instead of an 'example'. The
'example' (above that you request) is actually the long serious post (but
short enough to post) mentioned above.

------ semantic hole ---- semantic collision ------

When we view code we actually see if from several logical domains,
semantic viewpoints, stakeholder perspectives, subjective thought, etc.

These are all synonyms for 'logical domains'.

When we 'cube' the problem space we center the problem space and form a
'cube' of faceted logical perspectives around it. The 'hypothetical domain'
is either the problem space itself or (logically cast out) as another logical
domain if we start to deal with 'semantic synchronization' as herein.

Each 'facet' is a valid, common and inherent way of looking at the problem
space. The problem space is a subjective simulation of objective phenomena.
Subjective thought phenomena simulating objective reality.

Case in point. The hen house.

The fox and farmer both see the hen house from two different logical
perspectives. A good 'hen house design' takes into account the
'subjective role based' logical perspectives of farmer and fox.

As engineers and scientists the 'subjective role based perspectives' are
antithetical and confusing in the search for 'objective phenomena based
perspectives' (the search for 'truth').

Thus when I say 'semantic hole' it refers to a missing keyword or term in
ONE perspective in the 'surface area of the complete logical domain'
inscribed by multiple logical domains. Semantic hole (technically) means
somebody is trying to express the target phenomena (the problem space) but
doesn't have the 'right word' or a 'good word' for their desired SUBJECTIVE
MEANING. Note the personal subjective meaning and objective phenomena never
have
to agree. Community subjective meaning (jungian) expressed in all written
media
should agree in the semantics of community use.

The hypothetical logical domain (subjective simulator for objective
reality) MUST ALWAYS AGREE with semantics used in ALL FACETS of the
complete logical domain (that inscribes the hypothetical problem space).

Note that you must distinguish the different between a 'semantic hole' and
a 'semantic collision'.

A semantic collision is really 'my hip shot feeling' on the 'instance
name' vs 'variable name' issue. A semantic hole was just a shallow hip
shot of the mark (sorry :-).

So, I think we have a semantic collision that implies a semantic hole in
the formal C# spec (no big thing there, it wouldn't be the first time).
By this I mean english language semantics override C# spec semantics.

A semantic collision can occur because;

(A) One logical perspective trys to force its terminology on another
logical perspective (C# spec of english semantics used in C# architecture
and design discussions and specifications).

(B) Two logical perspectives use the same term that does not have
formally defined multiple meanings (multiple logical interpretations
matching the perspectives and/or context of use cases).

----- end of semantic hole ---- semantic collision explanation ----

All of this is covered and focused on C# english (and code) semantics in
the two posts. The short post uses LLP (Low level patterns) to track
the code semantics (instance, reference, etc).

So the two posts I mentioned would answer your 'example' request.

The short post (I think) is what you (as a hard core pragmatist) would
like to see. The minimal real world code fragment followed by semantic
discussion examples (in english text - not code text).

The long post is entitled :

C# reflection semantics across 5 logical domains

But I would like to 'work it a bit' to check on a potential '6th' logical
domain.

Please allow me to answer your immediate request (above) with this
incomplete answer. I hope the humor of the 'hard code' rewrite of your
example will be entertaining enough to be worth the wait.

Finally the 'real example' (Reflection semantics across 5 logical domains)
is pertinent to the community (IMHO) since our discussions in this venue
use english. But I fear it is probably too obtuse for this venue. So I'll
just check the response to the short humorous and (if good) post the long
version.

On a personal note. My grandfather could (reportedly) speak 52 human
languages (there are about 3,000 to 7,000). From him I seem to see
everything in multiple facets all at once. This has been more of a help
than a hinderance since I can 'morph' my technical jargon to any 'given'
perspective pretty darn quick (makes me popular with executives and
engineers - so far ).

I will post the (hopefully humorous) rewrite of your 'x and y - whats the
instance name' example.

Thank you as always for your input.

Shawnk

PS. Your (obviously) right that my terminology is 'out of spec'.

PPS. I'll post sometime this week (busy, busy)

PPPS. Mission and schedule are always my focus - this level of discussion
is generally for the architects, designers and book writers among us.
Personally 'I don't care' since I just morph my speech to the audience
(and usually pretty quick). As we approach speech based programming
and code automation however, semantic synchronization is a design issue.