Welcome to MSDN Blogs Sign in | Join | Help

Compiler information as part of code.

*** #ClassName : gives you the name of the current class

 

Often I setup loggers and stuff, and always do something like:

class blah

   static Logger Log = new Logger( "blah");

 

what I'd like to do is have a context aware statement that got built at compile time (much like the old C++ __line and stuff) -

eg:    static Logger Log = new Logger( #className )

 

We've talked about this, but haven't been able to come up with a clean way of doing it. We do understand the value.

 

*** #member : gives you the name of the member you are in

 

same as above, it'd be nice to be able to do things like put stuff about what procedure I'm in:

eg:

public void Blah()

{

    Log( #currentProcedure +  ": first line");

}

 

ibid.

 

*** "meta"  parameter definition

 

This is a little off the wall, but it'd be easy to do, and really cool - have a tag called "meta" which you can put on a parameter - which will actually compile to send information about the actual parameter

for instance, at the moment I have a thing called EnsureNotMissing( string, object), which just does a "if null throw exception (" parameter " + name + " is missing )

that means at the moment I have to say

      EnsureNotMissing( "myParam", MyParam );

 

I would like to build

      public void EnsureNotMissing( object MyParam, meta(MyParam) objectData )

      {

            if (myParam ==null)

                  throw new exception( (objectData as ParameterInfo).name + " is null");

      }

 

so I can just say

      EnsureNotMissing( MyParam );   - and the compiler will actually throw in the other stuff, like the name

 

This would be a nice feature. It's something we've touched on obliquely when we talked about __FILE__ and __LINE__

Published Thursday, April 22, 2004 9:03 AM by ericgu
Filed under: ,

Comments

Thursday, April 22, 2004 9:52 AM by J. Daniel Smith

# re: Compiler information as part of code.

How about wrapping the C# code with XML?

There was some related discussion on Channel9 a few weeks ago: http://channel9.msdn.com/ShowPost.aspx?PostID=1556 (there's a link to a very simple sample on my website in the conversion).

I think making the actual source code be XML would give you A LOT of potential to do all kinds of cool things.
Thursday, April 22, 2004 2:40 PM by John Rusk

# re: Compiler information as part of code.

>We've talked about this, but haven't been able to come up with a clean way of doing it. We do understand the value.

Please keep trying (to come up with a way) since it would be really handy, especially for data binding.

Is there anything on the web where Microsoft have documented the various options that have been considered? I.e. so that users can submit feedback or suggestions.

John
Thursday, April 22, 2004 3:18 PM by Erik Charlebois

# re: Compiler information as part of code.

Isn't this mostly aspect-oriented features such as those seen in AspectJ?

There was an AspectC# project floating around as well.
Thursday, April 22, 2004 5:36 PM by Jason G

# re: Compiler information as part of code.

Ummm, There *Is Currently* a way to get the currently executing method/class.

MethodBase.GetCurrentMethod().

The #meta thing would be much tougher, since what he is really asking for is what the source code name for that slot on the stack is, which would depend on debugging symbols and I imagine constrain what the JIT compiler can do to optimize code.


I would much, much rather have #file back. Possibly #line also, but I've had less use for that.
Thursday, April 22, 2004 6:10 PM by John Rusk

# re: Compiler information as part of code.

I guess the other thing that would be handy is some kind of summary of all the things that features like these might be used for. It seems like there are several different requirements that fall under the umbrella of "compiler information in the code". E.g.

- getting (compiler-checked) property names for databinding.
- getting information about the current method, line nor file.
- getting information about the parameters that have been passed to a method ("meta" above).
- what else?

John
Friday, April 23, 2004 9:28 AM by Alex Moskalyuk

# re: Compiler information as part of code.

I am sure I am not the first one to think of that, but wouldn't a clean way of doing that include a class like CurrentInfo, that would be perhaps in the Reflection or Runtime namespaces and would provide the attributed like CurrentFunctionName, CurrentClassName, CurrentClassNameSpace.

You could also throw in CurrentOS, CurrentCPU, CurrentNetworkName, CurrentIPAddress in there as well.
Friday, April 23, 2004 4:57 PM by John Rusk

# re: Compiler information as part of code.

After posting a few questions, above, I had an idea. Several of these requirements could be taken care of by a fairly "simple" mechanism which would allow identifiers to be treated as strings. It's hard to explain in this little text box :-) so I've described it on my web site instead, for anyone who may be interested. See:

http://homepages.paradise.net.nz/jjrusk/tech/id58.htm

John
Wednesday, April 28, 2004 6:07 PM by Brett Alcorn

# re: Compiler information as part of code.

How about "typeof()" with no arguments gives you the Type of the enclosing class? Then you could save typeof().Name

Another post nearby suggested having a "memberof" which works as follows:
- memberof(MyClass.MyProperty) returns a PropertyInfo
- memberof(MyClass.MyMethod) returns a MethodInfo [although problems identifying overloaded methods]

Then memberof() could return the MethodInfo of the enclosing method. Hence memberof().Name
Friday, May 14, 2004 1:01 PM by Kjell Holmgren

# re: Compiler information as part of code.

MethodBase.GetCurrentMethod() is great. I wish there was a PropertyInfo.GetCurrentProperty() as well. I haven't found a direct link from the meta for the currently executing property accessor method to the property. In order to account for compilers using other prefixes than "get_" or "set_", you will have to iterate through the PropertyInfo collection of the type in question and compare the return values of GetGetMethod() and GetSetMethod() to the value you get from GetCurrentMethod().

By the way, what about adding MethodBase.GetCallingMethod() while we are about it?

Anyway, the GetCurrentWhatever() obviously only work when you want to get the meta for the currently executing member. It will not work if you want to get the MemberInfo on any other member than the one executing right now.

What about introducing a keyword like "infoof" (or something similar, in the spirit of "typeof") that returns the proper MemberInfo derivation (e.g. PropertyInfo for a property, MethodBase for a method, etc.)? I am not the first one to think of this, (see Brett's post), but I think it can be expanded to work for any reflectable code entity, depending on context. I am mainly thinking of parameters here.

This way, you will not have to use a string with the property name doing a binding, for instance; you can take advantage of IntelliSense and the compiler to make sure that you do not misspell the name. If you were to rename the member, you would get a compilation error; I really dislike hiding important logic information from the compiler in strings...


I would like to be able to do something like this:

Type propertyType = ((PropertyInfo)infoof(myObject.MyProperty)).PropertyType;

object[] atts = ((MethodInfo)infoof(myObject.MyMethod)).GetCustomAttributes(true);

textBox1.DataBindings.Add(infoof(textBox1.Text), myObject, infoof(myObject.FirstName));


Using your example above, you could do something like this:

public static void ThrowIfNull(object value, MemberInfo memberInfo)
{
if(value == null)
throw new ArgumentNullException(
memberInfo.Name,
"Value may not be null.");
}

And call it thus:

ThrowIfNull(myParam, infoof(myParam));


An alternate solution to this particular problem would be to introduce a new attributes, say, "NotNullAttribute", where the compiler would insert the necessesary code to check for null on assignment to parameters, fields, and properties.

Come to think of it: why is Reflection referring to arguments as parameters (as in ParameterInfo) whereas the exception for a null parameter is called "ArgumentNullException"???
Saturday, December 18, 2004 10:51 AM by MBA

# MBA

Helpful For MBA Fans.

# Border Crossing Stats » Eric Gunnerson’s C# Compendium : Compiler information as part of code.

# Eric Gunnerson s C Compendium Compiler information as part of code | patio umbrella

New Comments to this post are disabled
 
Page view tracker