views:

266

answers:

6

Simple question, hopefully a simple answer:

I'd like to do the following:

private DateTime m_internalDateTime;
public var DateTimeProperty
{
   get { return m_internalDateTime.ToString(); } // Return a string
   set { m_internalDateTime = value; } // here value is of type DateTime
}

The above is just an example of what I'm trying to do. I'd like to have a public accessor to an internal variable of type x. I want the get that variable as a string, but set it using something of type x.

Is this possible?

--edit--

I just realized I could do something like:

private DateTime m_internalDateTime;
public object DateTimeProperty
{
   get { return m_internalDateTime.ToString(); } // Return a string
   set { m_internalDateTime = (DateTime)value; } // here value is of type DateTime
}

But then, let say I use type y instead of a "string" as my 'get' type. If I want to use "DateTimeProperty" else where in my code, I'd have to cast it.

+1  A: 

As a property, no this is not possible. You could make Get and Set methods that are of different types, but for a property the types must be the same.

EDIT:

While:

private DateTime m_internalDateTime;
public object DateTimeProperty
{
   get { return m_internalDateTime.ToString(); } // Return a string
   set { m_internalDateTime = (DateTime)value; } // here value is of type DateTime
}

is syntactically correct, will compile and allows you to accept DateTime as input and return a string, this would not be a good plan. It works, but it makes you and anyone accessing this code, perform unneeded validation. Additionally, it is vulnerable to another developer in the future, not knowing, or realizing the implicit rules, for which you have lost compile time safety. Additionally, its hardly any more code to create either two properties, or two methods that accomplish the same goal, in a strongly typed manner.

Personally, I would recommend using two methods (see Jeff Yates comment for a good explanation as to why).

private DateTime m_internalDateTime;
public string GetDateTime()
{
    return m_internalDateTime.ToString();
}

public void SetDateTime(DateTime dateTime)
{
    m_internalDateTime = dateTime;
}
Timothy Carter
+3  A: 

Not that way, but you can certainly have a second property that accesses the m_internalDateTime field.

public string DateTimeString
{
   get { return m_internalDateTime.ToString(); }
}
TheMissingLINQ
+1  A: 

No. You can obviously add the .ToString() in the calling code, but you can't do what you propose without different names like this:

private DateTime m_internalDateTime;
public DateTime SetDateTime { set { m_internalDateTime = value; } }
public string GetDateTime   { get { return m_internalDateTime.ToString(); } }

Or, even better to use methods instead of properties (as noted in the comments):

private DateTime m_internalDateTime;
public void SetDateTime(DateTime dateTime) { m_internalDateTime = dateTime; }
public string GetDateTime() { return m_internalDateTime.ToString(); }

Keep in mind that var is for implicitly, compile-time typed variables, not dynamic variables.

Definitely do not do what you noted in your edit. It introduced a break in convention, possible performance implications (albeit slight), and significant localization problems.

Michael Haren
If you're going to use GetDateTime and SetDateTime, they should really be methods rather than properties.
Jon Skeet
Eww, 183% agree with Jon.
Colin Burnett
Can I ask why one would make these methods rather than properties?
Nick
184% agree (that's right, I cloned myself by 84%...who need's feet anyway) - I win (but not at athletics or sock wearing)! :D
Jeff Yates
@Nick: Because methods are like verbs that do something to an object and properties are like nouns that say something about the object. SetDateTime and GetDateTime are verbs, therefore should be methods.
Jeff Yates
Obviously the names should be changed to represent what's actually being described, too.
Michael Haren
@Jeff Yates: Well said
Michael Haren
@JY: The analogy to verbs/nouns makes a lot of sense! I like it!
Nick
A: 

Simple answer no, to your outside code your property will behave the exact way that a field would, you can't have a property having different set/get types just as you couldn't have a filed be set with a type and when you request it's value get a different type back.

Keivan
A: 

how about:

private DateTime intDT;
public string DateTimeProperty
{   
      get { return intDT.ToString(); } // Return a string   
      set 
      { 
         DateTime dt;
         if (DateTime.TryParse(value, out dt))
             intDT = dt;
         else throw new ArgumentException(string.Format(
           "{0} cannot be converted to a DateTime.", value);           
      } 
}
Charles Bretana
A: 

Maybe that`s helps

public class TDecimal { private decimal? m_value; public bool HasValue { get { return m_value.HasValue; } } public decimal Value { get { return m_value.Value; } }

  public static implicit operator TDecimal(string a_value)
  {
     decimal d;
     if (decimal.TryParse(a_value, out d))
     {
        return new TDecimal() {m_value = d};
     }

     return new TDecimal() {m_value = null};
  }

  public static implicit operator decimal(TDecimal a_value)
  {
     if(a_value.HasValue)
     {
        return a_value.Value;
     }

     throw new ArgumentNullException("a_value");
  }

}

public class A { public TDecimal Prop { get; set; } }

A a = new A();

a.Prop = "123"; if (a.Prop.HasValue) { decimal d = a.Prop; }

Lukasz