0

Are these two statements the same?

if (dep.BirthDate.HasValue) {
  myObj.GetType().GetProperty("birthdate").SetValue(myObj, (DateTime)dep.BirthDate, null);
}


myObj.GetType().GetProperty("birthdate").SetValue(myObj, dep.BirthDate ?? null, null);

I only want to set the birthdate when it has a value, but I'd like to do it in 1 line.

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
chuckd
  • 13,460
  • 29
  • 152
  • 331
  • 3
    No, it's not the same - in the first case you set property value only if birth date specified (it will have original value otherwise), in the second case you always assign value to the property (either birth date or null). The outcome could be very different, e.g. if property setter throws `ArgumentNullException` – Sergey Berezovskiy Dec 24 '19 at 21:42
  • ok, is there a way to get the 1st condition in 1 line without an if? – chuckd Dec 24 '19 at 21:44
  • 1
    Encapsulating it in a method that does the if-check is the only way, AFAIK. – Ian Kemp Dec 24 '19 at 21:45
  • Agree with @IanKemp - you can write PropertyInfo extension – Sergey Berezovskiy Dec 24 '19 at 21:52
  • if `birthdate` is type of `DateTime` then `dep.BirthDate ?? default(DateTime)` should do the thing ... based on your previous questions it seems like you are reinventing the AutoMapper – Selvin Dec 24 '19 at 22:12

2 Answers2

2

As @IanKemp suggested, you cannot avoid if-check when you want to skip the property assignment. Do not confuse with assigning default value.

The simplest solution is to encapsulate a nullable value check and property assignment into single operation. To avoid passing PropertyInfo around, you can use the extension method: 

public static class ReflectionExtensions
{
    public static void SetValueIfNotNull<T>(this PropertyInfo prop, object obj, T? maybe)
        where T : struct
    {
        if (maybe.HasValue)
            prop.SetValue(obj, maybe.Value);
    }
}

Usage:

myObj.GetType().GetProperty("birthdate").SetValueIfNotNull(myObj, dep.BirthDate);

Or if you work a lot with nullable values and property settings is not the only thing you do, then you can write a nullable extension which will bring your code back to non-nullable path:

public static class NullableExtensions
{
    // Note that action has non-nullable argument
    public static void Invoke<T>(this Nullable<T> nullable, Action<T> action)
        where T: struct
    {
        if (nullable.HasValue)
            action(nullable.Value);
    }
}

This approach swaps things around - now you can invoke actions on the value of nullable variable if nullable has value:

dep.BirthDate.Invoke(date => myObj.GetType().GetProperty("birthday").SetValue(myObj, date));

Or even this way if you'll invoke single argument functions

dep.BirthDate.Invoke(myObj.SetProperty<DateTime>("birthday"));
Sergey Berezovskiy
  • 232,247
  • 41
  • 429
  • 459
1

First of all, this does sound like a Speed Question. So, the speed rant: https://ericlippert.com/2012/12/17/performance-rant/

Secondly, the only price you get for putting a lot of things into one line are:

  • a heck of a time to read it
  • a heck of a time to understand it
  • somehow a even worse time trying to debug it

The first one has 6 (six) places were either of the null Reference exceptions might hit. Also a cast and reflection. It is a Exception breeding ground. Whoever will have to debug that line 6 months from now, will get nightmares from it. And that can be you.

Code readability and debugability should come first. Try to limit it to 1 operation/code line, whose result you assign to a temporary variable, to get usefull Exceptions. Never be worried about the performance impact of temporary variables. Between the Compiler, the JiT Compiler and dead code detection those will propably cut out in release builds anyway.

Christopher
  • 9,634
  • 2
  • 17
  • 31