getting a reference to a property of an object

[hamerb]

So the line of code I'm working on is something like this:

func(ref obj.GetType().GetProperty(PopertyNameSring).GetValue(obj,
null))

This ofcourse doesn't work since the GetValue method gets me a read
only value, not a reference to the property.

I can't drop the 'ref' due to boxing. obj might be a primetive like an
int.

There is no interface supported by obj, I'm using configuration data to
learn about the properties and the configuration data is provided at
runtime.

So I'm wondering if anyone knows a work around for this, I have to
admit I'm not sure how to get around this problem.

 

[Bruce Wood]

PropertyInfo pi = obj.GetType().GetProperty(PropertyNameString);
object propValue = pi.GetValue(obj, null);
func(ref propValue);
pi.SetValue(obj, propValue, null);

 

[Jon Skeet [C# MVP]]

So the line of code I'm working on is something like this:

func(ref obj.GetType().GetProperty(PopertyNameSring).GetValue(obj,
null))

This ofcourse doesn't work since the GetValue method gets me a read
only value, not a reference to the property.

I can't drop the 'ref' due to boxing. obj might be a primetive like an
int.

What exactly are you expecting the above to do? Are you really sure you
understand what "ref" means?

See http://www.pobox.com/~skeet/csharp/parameters.html

In particular, what would you expect to happen if you were fetching a
read-only property, but "func" changed the value of the parameter?

I suspect you just don't need the "ref" at all.

 

[Bruce Wood]

I can't drop the 'ref' due to boxing. obj might be a primetive like an int.

I just read Jon's response, and then re-read this line in your post. I
agree with Jon: I suspect that you don't need the "ref".

You see, when you fetch the property value:

object val =
obj.GetType().GetProperty(PropertyNameString).GetValue(obj, null);

"val" will already be boxed if it's a primitive. If "obj" is a
primitive, then it is also already boxed, since you declared it as
"object". The "ref" doesn't help you in any way at all, except, as my
earlier post shows, it allows you to change the value that you pass in,
which presumably you want to then change the value of the property.

If you don't want to change the property's value, just fetch it and
pass it to "func", then you don't need "ref".

 

[Nicholas Paldino [.NET/C# MVP]]

I kind of know what you are referring to. What I do is create a
delegate like this:

public delegate T GetInstance<T>();

Then, I create a structure like this:

public struct PropertyReference<T>
{
public GetInstance<T> Get;
public Action<T> Set;
}

Then, you can write a function like this:

public static PropertyReference<T> GetPropertyReference<T>(object instance,
string property)
{
// Get the type.
Type t = typeof(T);

// Get the property.
PropertyInfo p = t.GetProperty(property);

// Create the return value.
PropertyReference<T> retVal = new PropertyRefernece<T>();

// Set the delegates.
retVal.Get = (GetInstance<T>)
Delegate.CreateDelegate(typeof(GetInstance<T>), instance, p.GetGetMethod());
retVal.Set = (Action<T>) Delegate.CreateDelegate(typeof(Action<T>),
instance, p.GetSetMethod());

// Return the reference.
return retVal;
}

Then, you can basically pass the property around, and get/set it
whenever you want. It's ^somewhat^ similar to setting a reference, but not
exactly the same, and there is no type safety here, as you can't validate
whether or not the property exists at compile-time.

Hope this helps.

 

[hamerb]

The reason i'm going this is for a decoder that decodes a stream into
an object based soly on configuration data.

All decoders support a singe interface, and the operate on an object, a
stream, config data and a decoder dictionary. The goal is to make the
deocders only bound to the configuration data and not the actual
objects I'm populating so the decoders can be reused for multiple
devices (they send the streams).

The reason I ran into the 'ref' problem was due to the problem that
some of the members might just be value types, this is where boxing
kicks in and I'm failing at actually setting the value on the object.

and when anything fails the exception will shutdown the system, this is
actually required behaviour. Uncertain behavior is considered much
worse as a non-functional system for our design so making the thing
nice and cranky is a benefit.

anyway thanks for the responese they have been a great help.