Justin du Coeur (jducoeur) wrote,
Justin du Coeur
jducoeur

[Programming] Wishlist #583 & 584: Constructor & Property Enhancements

This one is a pure C# language rant, which I believe applies almost word-for-word to Java as well, but I'm less up on the current state of that language.

I am noticing today, far from the first time, that I spend a ridiculous amount of time typing constructors. Here's the skeleton that I just typed (I don't think it gives away any company secrets to say that I'm writing a nice beefy resource-management system right now):
   internal class ResourceRequest
   {
      public ResourceRequest(string name, string resourceType, IDictionary other)
      {
         m_Name = name;
         m_ResourceType = resourceType;
         m_Other = other;
      }

      public string Name { get { return m_Name; } }
      public string ResourceType { get { return m_ResourceType; } }
      public IDictionary Other { get { return m_Other; } }

      private string m_Name;
      private string m_ResourceType;
      private IDictionary m_Other;
   }

That's terribly, terribly ordinary object-oriented code. Damned near every class has the same pattern: a constructor whose parameters simply get assigned to private members, and those members get exposed as properties. It's good programming practice -- very flexible, easy to modify the behaviour down the road, etc. But damn -- it's a lot of pointless verbiage, and boilerplate always gets under my skin.

So I'll add this to my Perfect Language Wishlist: it would be lovely to be able to condense all of this using some attributes and a little new syntax. I can easily see boiling the above down into:
   internal class ResourceRequest
   {
      public ResourceRequest(Name, ResourceType, Other)
      {
      }

      [ReadProperty("Name")]
      private string m_Name;
      [ReadProperty("ResourceType")]
      private string m_ResourceType;
      [ReadProperty("Other")]
      private IDictionary m_Other;
   }

This represents two specific enhancements. First, you can just declaratively say "expose this member as a read-only property" (there would obviously be a version for read/write as well), thus preserving the separation of the member and property in case we want to introduce indirections later, but stating the simple common case concisely. Second, you can simply give the name of a property as an untyped constructor parameter, meaning "assign this parameter directly to this property".

I'm not sure the above syntax is ideal -- it might want a little additional syntactic sugar to make it clearer -- but the basic concept is straightforward. If the language demands a very common piece of boilerplate, you should simplify the language to reduce that boilerplate.

Along these lines: it would be a Very Nice Thing to be able to specify optional properties as part of a constructor call. C# is curiously inconsistent in this regard. Attributes actually have exactly the behaviour I want, with things like:
[XmlElement(ElementName="foo")]
string m_Foo;

The above means "attach an XmlElementAttribute to m_Foo, and assign the value 'foo' to the ElementName property". This is a clean, elegant way to get a lot of flexibility in construction, and used properly would allow you to staunch the explosion of constructor signatures common in complex objects. But for some reason, they only allow it in Attributes -- you can't use the same syntax for ordinary C# objects, so you have to replace it with multiple lines of assignment, resulting in code that is both longer and muddier.

So the other immediate wishlist item is to steal this syntax from attributes, and allow any constructor invocation to do this. It would reduce code size immediately, and generally improve readability and maintainability by clarifying that these particular property assignments are intended as part of the initial state of the object...
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 3 comments