I suggest you ...

Allow multiple properties in a class to be changed at once, like some kind of "with" clause.

Delphi and VB have the ability to set multiple properties in one statement without having to refer to the parent object.

For example:

with myObject
.Prop1 =
.Prop2 =
.Prop3 =
etc

C# does have the class initializer syntax, which is great, but it would be better if we could do this AFTER the class has been initialized. Something like this:

with (myObject)
{
Property1 = "***",
Property2 = "yyy",
Property3 = "zzz"
};

58 votes
Vote
Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Simon shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

Thanks for taking the time to share this suggestion. This item has been around for a couple of versions of Visual Studio and we havenÕt acted on it. Looking at the VS Ò15Ó plans, weÕre not going to take action on this item, so weÕre going to close it. If the suggestion is still relevant, please either take a look to see if thereÕs another suggestion thatÕs similar that you can vote on, or open a new suggestion.

- The Visual Studio Team

5 comments

Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
Submitting...
  • Metro Sauper commented  ·   ·  Flag as inappropriate

    I find this concept most desirable when I have just called an object factory rather than using the "new" syntax.

    var o = objectFactory.GetNewObject().{ Property1 = "***" };

    I'd really like this to work without the "." operator so that it mirrors the "new" keyword.

  • Pavel Evgenjevich Timoshenko commented  ·   ·  Flag as inappropriate

    I propose the following version:

    alias(dst=myObject1.MyProperty.MySubProp, src =myObject2.MyProperty.MySubProp) {
    dst.Value = src.Value;
    if (src.Count ==10) dst.NValue = src.NValue;
    }

    or
    alias(myObject1.MyProperty.MySubProp, src =myObject2.MyProperty.MySubProp)
    {
    .Value = src.Value;
    if (src.Count ==10) self.NValue = src.NValue;
    }

    if aliased objects supported ISupportInitialize interface, the compiler generates following code:

    alias(dst=myObject1.MyProperty.MySubProp, const src =myObject2.MyProperty.MySubProp)
    {
    dst.Value = src.Value;
    if (src.Count ==10) dst.NValue = src.NValue;
    }

    try {
    ((ISupportInitialize) dst).BeginInit();

    dst.Value = src.Value;
    if (src.Count ==10) dst.NValue = src.NValue;
    } finally {
    ((ISupportInitialize) dst).EndInit();
    }

  • Paul Gardner commented  ·   ·  Flag as inappropriate

    This is one feature I wish would be removed from Delphi. I admit it reduces typing and can help clarify code. But it's not meant to be used to set "myObject" properties. It's more useful (in Delphi code) for something like:

    with TFoo.Create do begin .... end; OR
    with myObject.Children.AddNewChildToListAndReturnItHere() do begin ... end;

    Even in those cases a simple variable declaration handles all the benefits of the with statement.

    Why do I hate 'with'? Here's code from Malcom Groves (a blog):

    with Listbox1.Items, Table1, Form1 do
    while not EOF do
    begin
    Insert(0, FieldByName('COUNTRY').AsString);
    Next;
    end;

    While the developer intended the Insert statement to relate to the Listbox.Items, the Table1 object also has an Insert method, and as it appears further to the right in the list of operands, it will be evaluated first. Thankfully the compiler will pick this one up for you, as the method signatures are different.

    'Next' was actually intended to be related to the Table1 object, but again, TForms have a Next method with the same signature, so this one will be a little more difficult to track down.

    So let's pull the Table1 reference out of the with statement, and we'll end up with this:

    with Listbox1.Items, Form1 do
    while not EOF do
    begin
    Insert(0, Table1.FieldByName('COUNTRY').AsString);
    Table1.Next;
    end;

    Now we've introduced a new bug by forgetting to put Table1 in front of the call to EOF. This one wasn't a bug before, but EOF will now resolve down to the EOF function in the System unit.

    It's just not worth it for this. My $0.02 on the matter.

  • Simon commented  ·   ·  Flag as inappropriate

    @Metro Sauper. Yes that would work too. Another feature should be that the result of the statement is the parent object, meaning you could then chain a call off it:

    myObject.{
    Property1 = "***",
    Property2 = "yyy",
    Property3 = "zzz",
    }.DoSomething(123);

Feedback and Knowledge Base