C# Needs a Property keyword like MC++ has now

C# Needs a Property keyword like MC++ has now

• DirectShow

  Also I would be curious to see then a declaration of properties with only a get or set accessor or something more complex like this:
  
  

  private string data;
  public string Data
  {
    get { return this.data; }
    internal set { this.data = value; }
  }

  Would that then be:
  public property public get internal set Data;
  or how would you image something like that to look like

  Or if it is a property with only a get accessor, declared maybe as:
  public readonly property Data
  would that then implicitly be not readonly from inside the class

  What about properties where there is no direct relationship between a private variable and the property

  
  

• Sanjeev Menon

  I really don't buy that as a valid point. We use public methods from within a class all the time - why would it be any harder typing, say "Data" instead of "_data"
  
  Imagine if it were a public method called Data(). Are you really saying you have problems with calling a method called Data() from within your class methods Of course you don't. And it would be no different with having a public field called Data.
  
  The thing is, of course, is that you are not supposed to have public fields. You are supposed to expose them as properties AND VALIDATE THEM IN THE "SET" METHOD.
  
  I really have two questions:
  
  (1) What, from the viewpoint of calling code, is the semantic difference between the proposed:
  
  public property string Data;
  
  and
  
  public string Data;
  
  (2) What is the semantic difference from the point of view of code within the implementing class
  
  
  

• MarkyMark7

  The "get only" case is easy using the "readonly" modifier. Set only, different accessibility on get and set and having no backing store ivar are cases where you wouldn't use the simplified syntax. Just like the MC++ property case and the C# event case, you would still be able to create properties like you do today. BTW, did you know you can do this with events

  private EventHandler _clickDelegate;

  public event EventHandler Click {
  add { _clickDelegate += value; };
  remove { _clickDelegate -= value; };
  }

  The property syntax for C# would then be very similar to the C# event syntax. Use it if you want, which you would for a lot of cases of simple properties. Or implement the accessors yourself if you need more flexibility.

  
  

• KevinBacon12

  I'm agnostic on the matter myself; I think Visual Studio's refactoring features make it easy to wrap a property around a field rendering a property keyword kind of moot. But, I understand the need to make the language as easy to use outside of Visual Studio....

  Yes, it's syntactic sugar; but, I doesn't chance the security of the current get/set syntax--so, I don't think it give any false sense of security, it's no more "exposing" a field than the get/set syntax does. It gives flexibility of declaring a property as easy as a field but leaving it open to implement the get/set syntax without having to change the published interface.

  
  
  

• dioptre

  It's times like these I'm glad that C# has that code snippets feature. All we need to do now to create a property is:

  prop<TAB><TAB>
  Ctrl Right
  int/string/object/double/Type/whatever
  Right
  Type in property backer name
  Down down
  Type in property name
  Enter

  
  
  

• Giri

  Of course - it's so you can change the implementation without changing the interface (I knew that really. ;)
  
  So the proposed "property" keyword would be purely a shorthand, nothing else.
  
  I still don't like the idea, although I can see how it may seem attractive. However...
  
  I don't like the idea of making it too easy to expose fields as read/write values. Sure, you can do that right now by making the field public - but everyone KNOWS that's a bad idea. But it's not just a bad idea because you can't later change the implementation. It's also a bad idea because it allows clients to change the object's fields without the object knowing about it. Letting people do that just by saying "property" could lead them into a false sense of security.
  
  In my (humble) opinion, making it too easy will not encourage people to think about what they're doing. If you make them write the get/set functions, you force them to think about it.
  
  But - hey ho - if it went into the language, I wouldn't be hugely bothered.
  
  [EDIT]
  Looking on the Net, it appears people have been discussing this feature since 2002. :)
  I'll just go with the flow on this one. :)
  
  
  

• Prism

  I use that delegate syntax quite often for cleanup of dynamically created and bound objects.

  I see that the property keyword would simply the syntax in a special scenario, but I do not know if it is worth to break a consistent syntax (as the complete syntax is still required) to support lazy typers. Personally I think the keyword is unnecessary. After looking through some of my classes, I did only find one maybe two properties which just wrap a private variable. Most of the properties I found serve to give direct access to certain deeper structures which should not be fully exposed , e.g.:
  public string Namespace
  {
  get { return this.currentXmlNode.NamespaceUri; }
  }

  So probably even if this syntax would be provided I would most likely not use it, to keep a consistent style.

  
  

• stcdereke

  There seems little point to this proposed "Property" keyword. The way I look at it is:
  
  (1) If you don't need to do anything other than allow read access to the underlying field, you can simply use the "readonly" keyword (as someone already stated). In the example given, you can already do this in C#:
  
  

  private string _data; public string Data {     get { return _data; } }

  
  can simply be rewritten as:
  
  

  public readonly string Data;

  If you're allowing complete read/write access, then I'd wonder what your code was up to... It's equivalent to doing "public string Data;"...

  However it's possible that I'm not understanding the nuances of what the "property" keyword would do. From the point of view of calling code, what would be the semantic differences between:

  public property string Data;

  and

  public string Data;

  
  
  (2) If you DO need to do anything other than allow simple read access to the field, you couldn't used the proposed "property" keyword anyway.
  
  So, what's the point It would just end up being a synonym for "readonly"...
  
  By the way: Someone mentioned that they wanted to keep the property get/set methods separate. I do that - where appropriate - by putting them into a separate file via the power of partial classes. I always call that file <classname>.Properties.cs, where <classname> is the name of the class. I also edit the CSProj file so that the ".Properties" file appears nested under the primary class name (just like ".resx" files do).
  
  Now THAT is something I wish the IDE would do - allow you to nest partial class files under the parent class from the IDE!
  
  
  

  
  

• OdinsBlade

  I also agree.

  Regarding IDE capabilities that make writing properties easier or keep them out of sight - the IDE should never be used as an excuse not to streamline the language experience. The vast majority of properties are mind-numbingly devoid of logic and the 11 lines used to represent them (if using the standard of braces on separate lines) is just clutter.

  David Anton
  www.tangiblesoftwaresolutions.com
  Instant C#: VB to C# Converter
  Instant VB: C# to VB Converter
  Instant C++: C# to C++ and VB to C++ Converter
  Instant J#: VB to J# Converter
  Clear VB: Cleans up VB code
  Clear C#: Cleans up C# code

  
  
  

• elaechelin

  I completely agree with Keith. I have hundreds of get/set methods in my programs. Not only are they very annoying to write, but it is easy to forget one and then your program won't compile ... again. And in VS, regions frequently auto-open, so it's hard to keep them out of sight, too.
  

• Hagen O.

  "It gives flexibility of declaring a property as easy as a field but leaving it open to implement the get/set syntax without having to change the published interface."

  That's a good synopsis Peter. The major issue I had with COM programming was all the stinkin' boiler plate code you have to write. I hate that. Now if C# somehow had the same defmacro facility that Lisp has then we wouldn't need Microsoft to add syntatic sugar features like this. We could do it ourselves. :-)

  
  

• RikMertens

  You are forgetting that we would want to use the thing within the class. That means that we would be replacing one kind of clutter with another: inconsistent use of capitals. Not only would that cause a lot of typo's in this name, but it would also cause typo's in names where we do also have a property, and those may lead to all kinds of problems that are awfully hard to track down.

  Regards,

  Guido

  
  

• osmansays

  I'm sure there will be folks who don't use the new syntax just like there will be folks who don't use some of the new C# 2.0 or 3.0 features. However the language has to "keep up" or eventually it will be rendered irrelevant. Dynamic languages and dynamic development styles (like Python, Ruby on Rails, REPL, etc) are on the rise and for good reason - they make developers more productive. Admittedly simplified property syntax is minor in this context but then again I think it is also low hanging fruit. C# 3.0 will go a little way towards addressing productivity but interestingly it seems that the additions are coincidental and were put in mainly to support LINQ. BTW, I'm not arguing for a dynamic/loosely typed C#. However there are plenty of ways the compiler/runtime can make us more productive by eliminating "line noise" and boiler plate code (which is what I consider the current degenerate property get/set code to be).

  
  

• Notes

  (1) What, from the viewpoint of calling code, is the semantic difference between the proposed: public property string Data; and public string Data; (2) What is the semantic difference from the point of view of code within the implementing class

  There's no syntactic different between accessing a field and a property in C#, they're both accessing a member of the class, e.g. object.member. Semantically, they're very different. object.property is short-hand for either object.get_property() or object.set_property(). Obviously, from a client applications point of view these are two drastically different things, which cannot simply be interchanged. You would not simply be able to switch from a field to a property and expect a client application to be able to find that member any more.

  That's one of the points of being able to easily add a simple property to a class. A simply property makes the class easier to evolve. If that property needs to exand to use lazy-eval, or perform a calculation (as opposed to a "static" value stored in a field) the interface need not change. If you started out with a field you would have to change the field to a property and change the published interface; breaking any client applications.

  
  
  
• C# Needs a Property keyword like MC++ has now