With Feature

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Why was not included , like in VB.Net the With feature.
In VB you can use an Object like this.

With MyObject
.Text = "Hi"
End With

Or like jScript

with (MyObject)
{
Text = "Hi";
}


Why it is not present in C#?
 
Why was not included , like in VB.Net the With feature.
In VB you can use an Object like this.

With MyObject
.Text = "Hi"
End With

I'm a VB guy stretching my C# legs. I have always been under the impression
that the With feature was specific to VB. I miss it in C# too. It makes
the source code easier to type, easier to read, and it runs faster too,
because the pointer only has to get resolved once.

I haven't looked, and it doesn't interest me enough right now to check it
out, bue the C# compiler might be smart enough to generate MSIL that's
analogous to the VB implementation of the feature.
 
Mike Labosh said:
I'm a VB guy stretching my C# legs. I have always been under the
impression that the With feature was specific to VB. I miss it in C# too.
It makes the source code easier to type, easier to read, and it runs
faster too, because the pointer only has to get resolved once.

Actually, readability is one of hte big reasons *not* to use with, IMHO. The
last thing readability needs is another indirection from what you are
actually using.
I haven't looked, and it doesn't interest me enough right now to check it
out, bue the C# compiler might be smart enough to generate MSIL that's
analogous to the VB implementation of the feature.

No, the compiler does not generate any With like code and for good reason. A
With block implies a singular instance of a property\method\variable value,
while straight code doesn't make such guarentees. If the compiler starts
optimizing away accesses it will cause non-obvious bugs when a properties
value changes between or due to calls. Such a practice is unadvisable but
making the compiler break such patterns would be horrendous.

If you really want to emulate with, the simple pattern is:

MyObject o = x.y.z.longname.myObjectProperty;
o.A();
o.B();
o.C();

And, finally, from the horses mouth:
http://msdn.microsoft.com/vcsharp/team/language/ask/withstatement/default.aspx
 
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

Besides, the compiler already supports shortcuts such as the using(...) and
foreach(...) blocks.
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.
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#.

True that WITH does not offer anything to the language that cannot be coded
some other way, but that can easily be said about numerous other constructs.
 
I'll just toss my two cents in here... a 'with' statement cetainly reduces
the amount of text in the code, but it DOES NOT improve readability. In
fact, in my code, I always use the full namespace when declaring objects,
just so there is no confusion as to where it is coming from. While it might
be easier on _your_ eyes if there is less code, it will be easier for another
developer if the code has as much 'self-commenting' as possible.

-James
 
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?
 
Back
Top