Peter Rilling said:
I did start my career developing with VB, but I have been using C# for the
past five years and even I think that the WITH statement would be
beneficial. After reading the article mentioned, here are my takes on
their
specific bullet points.
1) I my opinion the readability is improved. It seem to me that
With MyDataStructure.GetButton(44)
.Text = "Hello"
.BackColor = Color.Blue
End With
is easier to read then
Dim b as Button = MyDataStructure.GetButton(44)
b.Text = "Hello"
b.BackColor = Color.Blue
I disagree, but much of that is personal preference.
Besides, the compiler already supports shortcuts such as the using(...)
and
foreach(...) blocks.
The primary difference with those vs with is that they either act on an
existing variable or define a new one, with creates a scope with new lookup
rules.
Somehow I don't think
with (object x = myObject.ObjectField)
{
x.ToString();
}
does much for you, although that is the pattern foreach forces and using
generally provides.
2) Compilers are complex to begin with. Adding a WITH statement would
have
just mean that there would be an additional scope level to deal with. The
compiler already has to deal with determining if something is a class vs.
local variable.
Adding it to the compiler is simple enough, I could add it to mono's
compiler in a couple hours(mostly because I'd have to special some method
resolution stuff). The issue is more changing the language to support method
call syntax with the with statement, (the .Method()) or changing method
resolution within a scope block. It complicates human understanding of the
language by changing the rules mid-stream.
C# is actually a rather simple language. The syntax is pretty consistent
across the board(there are a few abberations, of course, stackalloc is kind
of odd). There are no oddities like VB has(or had) with the .Method() syntax
used in WIth blocks, optional parentheses(are they still optional\weird? I
havn't used vb.net much, I just remember parenthese issues in VB6), or
builtin language intrinsics. Changing it to support WIth more or less forces
that, and that really is undesired.
Of course, that isn't to say that VB is badly designed or even is
inconsistent, just that in this case the design goals differ. C# strives to
be consistent(even at the cost of capability) and library driven while VB
works towards customization and immediate simplicity, even if it costs a
little bit in consistency
You can see it everywhere in the two languages. C# has structs, interfaces
and classes. VB has structures, interfaces, classes, and modules. C#'s
equivlilent to a module(in 2.0 anyway, 1.x had none) is achieved by a
modifier to the class declaration.
C# requires partial on every part of a partial class, vb requires it on only
one.
VB has several casting\conversion operators with a considerable amount of
functinoality, C# has 2 and pushes everything else out into the library.
VB has two types of method(Sub and Function), C# has one.
You could spend all day comparing them(which is part of why I really hate
the "they are just skin around the framework" notion. The langauges are
fundamentally different, their users think differently, they solve different
problems and the same problems in different ways). With fits really well
into the VB paradigm...I am just not so sure that it does within C#.
3) Although C# is similar to C++, the statement about not including it
because it was never part of C++ does not make much sense. Optional and
Default parameters ARE part of C++ but were never included in C# so there
is
no real correlation between something existing in C++ and in C#.
I agree this is weak, but on the same hand they were not compelled to add it
as the VB folks were. Could you imagine the uproar if VB.NET didn't support
with?