New VB (or C#) ​Simplificat​ion Feature

I just found myself creating a composite control where I wanted to expose several properties of controls placed on my usercontrol as if they were properties of the control I was constructing.

Specifically, I was trying to expose the contextmenu properties of several controls Through names like ListContext, TreeContext etc.

Code for this runs something like

Property ListContext() As ContextMenu
Get
   Return SomeListBox.ContextMenu
End Get

Set(ByVal Value As ContextMenu)
   SomeListBox.ContextMenu = Value
End Set
End Property

There is nothing so special about the code above. It read and writes to the same place. But if you have dozens of these properties. you code can get a bit unwieldy.

Hows about a new language feature in Vb.Net and if anyone thinks it would be useful, In c# aswell.


Property ListContext Exposes SomeListBox.ContextMenu

And the Readonly version

Property Readonly ListContext Exposes SomeListBox.ContextMenu

I think this would make code an aweful lot easier to read and manage.

If needed we could even have a feature to expand this new syntax into the old syntax.

The phrase 'Old Syntax' is of course completely unfair.

Clearly we still need the 'Old Syntax' for properties which are not as straight forward as detailed above.

but hopefully this idea is both simple and useful

Comments please

Rory

I'll second that!  Having "simple" properties (where the property is just an accessor for a class member) take up many lines of code clutters code quite a bit.

Please consider making

  property string UserName;

Expand to code quivalent to:
 
  string _userName;
  public string UserName
  {
    get
    {
      return _userName;
    }
    set
    {
      _userName = value;
    }
  }

(Or explain why not )  Thanks.

stevex wrote:

I'll second that!  Having "simple" properties (where the property is just an accessor for a class member) take up many lines of code clutters code quite a bit.

In the upcoming version of Visual Studio (Visual Studio 2005, I think they're calling it now), there are two ways that I know of to do this. Existing fields can be expanded to field backed properties through the new built-in refactoring tools, and there's a feature called "expansions." In this case, to use the expansion, you would type "prop" and hit tab you'd get some code that looks like this:

private int myProp;
public int MyProp
{
   get{return myProp;}
   set{myProp = value;}
}

Hit tab again and [int] is highlighted, change it and it's changed in both places. Hit tab again to change myProp, and again to change MyProp. There are also "props" and "propg" expansions for restricting settable and gettable properties respectively. It's pretty slick and all of the expansions are defined in an XML file that you can edit to fit your coding style. You can also create new expansions and register them with VS. Unfortunately, all of the information I've seen about them suggests that they're a C# feature only, I'm not sure if that's true, but I hope not.

Dan Fernandez talks about how to make your own expansions in his blog.

As far as saving clutter space by making a single line act like a property rather than a field. I'm not sure I understand the benefit of that. Why not just use a field? I tend to like using properties rather than fields for a couple of reasons, either I'd like to add constraints to the property, and I feel that this is the best place to do it, or, like Rory, the property is actually backed by something more complex than a simple field.

-Bryn

However the idea in this case is not to expand the code at all but to add a language feature that evaluates to the same as the expanded form. VB did this in the last version (1.1) Allowing

For a as integer = 1 to 10
Next

Rather than

Dim a as integer
For a = 1 to 10
Next

So you see that in the suggestion made at the start of this thread, you have not only less code to type (as with expansions) but also less code to read when you come back to it later.

Rory

This would be a great idea, BUT what happens if SomeListBox isn't initialized?
The compiler can't detect that, so it's up to the caller to ensure that SomeListBox is properly initialized (thus breaking encapsulation), or enclose the call in a try ... catch block. In any case, the resulting code would be either ugly or brittle.


BTW, Delphi allows field-backed properties, but won't compile if you try to expose another object's property.

Well, lets think about that for a moment.

What happens if you try to read a property Where the underlying object is a reference type and its value is null or nothing?

Well you get a null reference exception

and if the underlying type is a value type then you return 0 or whatever the default value of the value type is.

This is the case no matter which coding expression you use.

Either ensure that all such reference type properties are initialised (maybe in the constructor of the object) or use the expanded form of property declaration.

Remember that for composite control creation with user controls you will likely not come across this problem since you will likely expose properties of other objects happy with the knowledge that the object in question does exist since you can see it there in the usercontrol designer.


Again this is suggested as a language extention. Some call it compiler magic.

but all it really does is give you a way to shorten the code you type and make that code easier to read, without changing the meaning of the code one iota.

Any chance we could get an MS opinion from one of the compiler teams?


Rory

I understand I can use expansions in Whidbey but you're missing the point.  What I want to do is unclutter my code, not have the IDE make it easier for me to clutter it

If members behaved the same as properties then I wouldn't be asking for this, but they don't.  For example, if you want to serialize using the XmlSerializer, you need to expose a property.

class MyStuff
{
  public string WontGetSerialized;

  string _willGetSerialized;
  public string WillGetSerialized
  {
    get 
    { 
      return _willGetSerialized;
    }
    set
    {
      _willGetSerialized = value;
    }
  };
}

I could wrap it with a #region to try to make it look like one line in the editor, but then we've taken what should IMHO be one line of code and turned it into 10 lines that only look "right" in a particular editor.

 - Steve

If serialization is your reason for exposing fields as properties, the deep serialization techniques offer an alternative.

This Builder.com article explains the difference...

http://builder.com.com/5100-6389-5116498-2.html


and the MSDN documentation has some example code...

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemruntimeserializationformatterssoapsoapformatterclasstopic.asp