Tech Off Thread

8 posts

New VB (or C#) Simplification Feature

Back to Forum: Tech Off
  • RoryBecker

    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
       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


  • stevex

    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
          return _userName;
          _userName = value;

    (Or explain why not Smiley)  Thanks.

  • Bryn Waibel

    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.


  • RoryBecker

    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

    Rather than

    Dim a as integer
    For a = 1 to 10

    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.


  • pkanabos

    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.

  • RoryBecker

    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?


  • stevex

    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 Smiley

    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
          return _willGetSerialized;
          _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

  • samunro

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

    This article explains the difference...

    and the MSDN documentation has some example code...

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.