Overloading Properties in C#

Navigation

I recently read some text indicating the reasons that C# doesn't support overloaded properties. I also tried this in Whidbey Beta 1 and it remains the case. However, i am a little more interested in why this is and what people think about it. To be specific, the following will not compile :

public string Author
{
set {_author = value;}
get {return _author;}
}

public AuthorEntity Author
{
set {_authorEntity = value;}
get {return _authorEntity;}
}

Why would you ever want to do this? Well, in my case, there are occassions in the "Book" class where the user may wish to define the author as a primitive string such as "Steven Livingstone". However, there are other cases where people want to declare that the author is the *Author* (derived from Person) who has the name "Steven Livingstone" - allowing them to further populate the Author class.

So i would like to say:

MyBook.Author = "Steven Livingstone"

MyBook.Author = MyPerson;

... and let the compiler figure out which it is using, in much the same way as overloaded methods work.

The ability to overload properties is pretty fundamental to the way of thinking i have for a project i am working on just now and so further suggestions would be appreciated. I could just always use the Author class, but that is an overkill for times when only the name of the author is to be set. I guess i could use SetAuthor() and GetAuthor() and overload these methods to accept the string and Author parameters - just not as nice as using properties directly.

steven

Posted: Aug 27 2004, 08:57 AM by stevenL | with 10 comment(s)

Comments

m7 said:

good luck trying to overload GetAuthor() ;) you will be attempting to overload a function which differs only by return type, and it won't compile. this is why properties can't be overloaded in the way you want - because they are converted to get functions which would only differ by return type.

nice idea but the compiler couldn't possibly know which to give you when you did this:
object author = MyBook.Author;

also personally i think it's not clean to do this:
MyBook.Author = "Steven Livingstone";
MyBook.Author = MyPerson;

but rather u should be doing this:
MyBook.AuthorName = "Steven Livingstone";
MyBook.Author = MyPerson;

or even better this:
MyBook.Author.Name = "Steven Livingstone";
MyBook.Author = MyPerson;

# August 27, 2004 4:49 AM

Steven Livingstone said:

Hi. Yes - i use an enum to tell me what one i am after in the method impl.

Creating a class when some people don't need it just seems overkill to me. Especially if the class is complex. "MyBook.Author.Name" may seem odd to someone who is just recording a persons name... especially if you could further break down "Name" e.g. "MyBook.Author.Name.FirstName", "MyBook.Author.Name.SecondName" and so on.

I'll probably go with the "class for everything" version as in theory every item may have further statements made about it and so will have to be identifiable (e.g. via a URI) - unlike the primitive types.

# August 27, 2004 6:48 AM

marco p said:

a simple workaround for the set accessor could be having an object property and then checking the type:

using System;

public class MyDemo
{
public class CustomerClass
{
public string Name;
public int id;

}

private CustomerClass _customer;

public object Customer
{
get
{
return _customer;

}

//overloaded set accessor
set
{
if (value is System.String )
{
_customer= new CustomerClass();
_customer.Name=((string)value).Split('!')[0];
_customer.id=int.Parse(((string)value).Split('!')[1]);
return;

}
if ( value is CustomerClass)
{
_customer=value as CustomerClass;
return;
}

throw new Exception ("invalid type");

}
}
}
public class MyClass
{
public static void Main()
{

MyDemo MD= new MyDemo ();

//as a string
MD.Customer = "johndoe!34";

//or as a CustomerClass
MyDemo.CustomerClass Cust= new MyDemo.CustomerClass();

Cust.Name="janedoe";
Cust.id=35;

MD.Customer=Cust;

//or ...invalid!
MD.Customer=8;
}
}

# August 27, 2004 6:57 AM

Paul Wilson said:

An API should be discoverable (simple/usable) also, and I think having overloads that differ only by return types defeat this goal. Yes, its a little more work to create a SetMethod with overloads, but that will provide a much better experience for the users of your API.

# August 27, 2004 8:01 AM

Brenton House said:

You should just create an implicit (or explicit) operator.

public static implicit operator Author(string authorName)
{
Author author = new Author();
author.Name = authorName;
return author;

public static implicit operator string(Author author)
{
return author.Name;
}

# August 27, 2004 9:37 AM

Scott said:

Well you could have all your proprties defined as "objects", then you could pass in whatever you wanted. (JK) :)

"Creating a class when some people don't need it just seems overkill to me."

Are you sure you wouldn't ever use an "Author" class anywhere else in the application?

Remember you don't have to set the "Author.Name" like this.

MyBook.Author.Name = "Steven Livingstone";

YOu can set all the "Author" properties and then set the "Author" property of the "MyBook" class.

MyBook.Author = new Author("Blinkin VonShivenheinshor");

# August 27, 2004 10:33 AM

Jeff Gonzalez said:

All books will only have 1 Author?

AuthorCollection authors = new AuthorCollection();

authors.Add(new Author("Jeff Gonzalez"));
authors.Add(new Author("Steven Livingstone"));
MyBook.Authors = authors;

Much nicer IMHO

# August 27, 2004 10:55 AM

Steven Livingstone said:

Brenton :
Interesting.
I played around and that initially looks ideal. I can now get the usability i want. It still creates an instance of the class behind the scenes for a single value, but at least to the consumer it makes things a little more inituitive.

Book book = new Book();
book.author = "Steven";
book.author.Name = "Steven";

thanks. Now to test how it goes in my masterplan.

Scott :
I may use the Author class again, but i am working on a system that allows many thousands of properties which fall into the category of "sometimes primitive", othertimes "complex". A constructor was one way i was considering.

Jeff :
Not only 1 author, perhaps an array of author Strings - as opposed to a collection of author classes when you only need to set one property.

# August 27, 2004 12:03 PM

TrackBack said:

^_^,Pretty Good!

# April 10, 2005 2:02 AM

GS said:

I am with you Steven. I am sure life would be easier if overloading of properties were a viable feature.

# April 17, 2008 7:30 AM

life in a smart mob

Recent Posts

Tags

Navigation

Archives