I am C# developer. I really love the curly brace because I came from C, C++ and Java background. However, I also like the other programming languages of the .NET Family such as VB.NET. Switching back and forth between C# and VB.NET is not really that big of deal if you have been programming for a while in .NET. That is very common approach in the company where I work. As C# guy, I really like the XML literal and with
keywords provided by the VB.NET compiler. I wish Microsoft had included those features in C# also.
I am just curious , what other developer has to say about it!
You can replace VB.Net's
With
by creating a quick single-letter variable name. It's actually less code, sinceWith
also requires anEnd With
later on.For example, one thing I used to need to do fairly often was iterate over the rows in a datatable for a control/break style report.
In vb.net, that might look like this:
The C# would look like this:
The thing to notice here is that the C# version actually needed less typing, because the VB couldn't combine
WITH
with the array index, and had to go through the.Item
property for certain things. It's not a big deal here, but imagine if the report had 20 fields instead of 2 and had to break on 3 items instead of 1.Of course, you could use the technique demonstrated in C# for VB as well. But the main thing to note is that
WITH
doesn't really give you much.I wouldn't be suprised if "With" or a similar feature is added to C# eventually along with other heretofore popular exclusively VB features. There was a lot of talk in the C# 4.0 preview presentations recently at PDC and elsewhere of the increased "focus on language parity" starting with C# 4.0 and VB 10.
It's about developer preferences, but I'm with you about WITH. My preference is to minimize the number of variables in play, and the scope within which they live. The philosophy of C# seems to be much the same. But in this case the responses here seem to suggest that adding (and making yourself responsible for) a variable is a Good Thing compared to a construct which, to me, is very similar to lambdas.
I feel it is rather arbitrary to only allow 'mass' property setting during initialization. I really don't get why this would be 'bad':
I feel that this example code is clean and concise.
Personally I don't like WITH when it's used after construction - if you need to do several things with an object after it's initialized, usually that behaviour should be encapsulated in the type itself. If you really want to do something like WITH, it's only a matter of declaring a short variable and optionally introducing a new scope.
However, it is useful to be able to compactly initialize an object with several properties - which is precisely why C# 3 allows you to write:
There are limitations to this (which the optional and named parameters in C# 4 will help to overcome) but it's better than it was without leading to potential messes/ambiguities.
(On the XML literal front, I'm again with the C# team - XML is a very specific technology to put into a language. If they could come up with a generalised form which happened to create XML but could be used to create other trees too, that would be nice - just as query expressions aren't directly tied to IEnumerable or IQueryable.)
Usually when I see a request for a
with
feature in C#, I see code that would benefit from refactoring. Usually when the refactoring is done, the supposed need forwith
is gone.I like the way my code works out when I build a fluent interface in to an object; it has some similarities to
with
. If I was designingMessageBox.Show()
, I might write:You can also see something similar with Linq:
It feels a bit like
with
but seems to fit naturally in to the language I already have.