StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
19358557
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2013-10-14T10:48:57.930
FavoriteCount
0
LastActivityDate
2013-10-14T10:54:48.973
LastEditDate
2013-10-14T10:54:48.973
LastEditorUserId
2035384
OwnerUserId
2035384
ParentId
19357717
PostTypeId
2
Score
1
ViewCount
0
LastEditorDisplayName
text
Body
First of all you can't query the runtime for the that information magically, implicitly. It is true that you can implicitly learn the complete identity of the currently executing method, its caller, its caller's caller and all of the stacktrace (except for the particular generic arguments in case of generic methods) by instantiating the <code>StackTrace</code> class or by calling the <code>MethodBase.GetCurrentMethod()</code> method. It is also true that the resulting <code>MethodBase</code> instances hold information about the methods' parameters and so, you might be able to learn the names of the parameters, but that's where it all ends. If a mechanism allowing you to implicitly probe for parameter or local variable values would've been invented then everything would be a lot slower. What you can do, is help yourself, a bit, by means of the <code>Expression<Lambda></code> class and its entourage. It's gonna be a bit slow, but you get to choose whether you want reviewable and easy to manage code, or misteriously hard to manage and very very fast code. <code>Expression<Lambda></code> is how LINQ manages to not do a full table scan of database tables but rather understand what you did with your query and translate that (at runtime) into SQL or whatever other language you might imagine (depending on the actual LINQ provider). First of all, I would suggest splitting concerns into 2 categories: <ol> <li>Retrieving names and values (as implicitly as possible)</li> <li>Using names and values (wherever you want to)</li> </ol> To make that happen you need to think about an entity which can hold the results of point 1. In my suggestion to you that would be a kind of <code>Dictionary<string, object></code> but you can do whatever suits you best. My suggestion can be used like so: <pre><code>public void SomeMethod(string x, int y) { IDictionary<string, object> paramValues = Helper.TapInto( () => x, () => y ); // paramValues["x"] an paramValues["y"] will hold the values of x and y } </code></pre> So, on to the coding bit. You could write a <code>Helper</code> class like so: <pre><code>public static class Helper { } </code></pre> In that <code>Helper</code> class you could invent a static method ( I called mine <code>TapInto</code> maybe that's not the best name for it ) which receives a primitive array of <code>Expression<Func<object>></code> instances. It does that with a <code>params</code> modifier so that you can easily pass implicit lambdas to it. As a return it gives you a hashtable from <code>string</code> to <code>object</code> representing the "decompiled" variable names and their associated values. In my case, I also created a private overload of that same method which is actually an "extension" method, to make the code clearer. <pre><code>public static class Helper { // ... an overload of the TapInto method is about to appear right here public static IDictionary<string, object> TapInto(params Expression<Func<object>>[] parameterTouchers) { var result = new Dictionary<string, object>(); foreach (var toucher in parameterTouchers) { string name; object value; toucher.TapInto(out name, out value); result[name] = value; } return result; } </code></pre> So all the public method does is iterate through the list and accumulate the yielded results into the dictionary. Next let's look at the real magic, which happens in the <code>toucher.TapInto(out name, out value)</code> call: <pre><code>public static class Helper { private static void TapInto(this Expression<Func<object>> @this, out string name, out object value) { Expression expression = @this.Body; if (expression is UnaryExpression) expression = (expression as UnaryExpression).Operand; name = (expression as MemberExpression).Member.Name; Func<object> compiledLambda = @this.Compile(); value = compiledLambda(); } // ... public helper method right here } </code></pre> What we're doing here is "we're looking inside" the lambda with a magnifying glass. Because we're gonna use stuff other than <code>object</code> variables it's imminent to observe an implicit conversion like <pre><code>.. int someParameter .. object obj = someParameter; </code></pre> which is only implicit in the actual C# code, but is actually compiled as an explicit conversion: <pre><code>object obj = (object)someParameter; </code></pre> But you might have a plain <code>object</code> parameter, like <code>object anotherParam</code>, in which case there would be no conversion at all. That is why, upon observing the expression's intricate details, I presume I might find a conversion ( represented by the <code>UnaryExpression</code> class ) or not. Actually it's like saying: In this particular case, my contract to the calling code is that it may send me only stuff which falls into these 2 categories: <ol> <li>Immediate <code>object</code> variable reference: <code>() => someObjectVariable</code></li> <li>Variable reference with a conversion: <code>() => (object)x</code></li> </ol> The contract also accidentally states that the "conversion" bit can be replaced by a <code>UnaryExpression</code>, for instance: <code>() => !someBool</code>. It also states that you cannot do something like: <ul> <li><code>() => 123</code> </li> <li>or <code>() => a + b + c + 100</code></li> <li>or anything else in those directions</li> </ul> So, to wrap it up: <ol> <li>You could write your nice little helper</li> <li>You could use it wherever you want to use it to produce maps between param names and their values although it's not 100% implicit, but at least it won't compile if you rename a parameter without complete refactoring or it will let you rename the parameter references if you choose to rename the parameters using refactoring (it also works on fields, local variables, etc)</li> <li>Pass your dictionaries in between parts of your code that are interested in them and use them accordingly !</li> </ol>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POGetting parameter name and value from delegate
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USEduard Dumitru
UserOwnerUserId
1. USEduard Dumitru
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. This table or related slice is empty.
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.