C# has VB's "with" command?

[abc my vclass]

C# has VB's "with" command?

I like VB's with command, why don't know C# has it or not?

[Pohihihi]

'With' is a statement in VB. It would have been a nice addition to C# but it
is not so for now. You have to fully qualify Object.Proporties in C#

http://msdn.microsoft.com/library/de...rdsptozvba.asp
http://msdn.microsoft.com/library/de...eywords_pg.asp


"abc my vclass" <my********@myclass.com> wrote in message
news:e6**************@TK2MSFTNGP11.phx.gbl...

C# has VB's "with" command?

I like VB's with command, why don't know C# has it or not?

[Nicholas Paldino [.NET/C# MVP]]

I disagree with the statement that it would be a nice addition to the
language. Check out the following "ask a designer" section on the MS
website for more information on why it was left out:

http://msdn.microsoft.com/vcsharp/pr...t/default.aspx

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Pohihihi" <no*****@hotmail.com> wrote in message
news:ec*************@TK2MSFTNGP10.phx.gbl...

'With' is a statement in VB. It would have been a nice addition to C# but
it is not so for now. You have to fully qualify Object.Proporties in C#

http://msdn.microsoft.com/library/de...rdsptozvba.asp
http://msdn.microsoft.com/library/de...eywords_pg.asp


"abc my vclass" <my********@myclass.com> wrote in message
news:e6**************@TK2MSFTNGP11.phx.gbl...

C# has VB's "with" command?

I like VB's with command, why don't know C# has it or not?

[Pohihihi]

Reasons given on the link are actually no better than "I want it cause it is
easy for me to work like that". MS was never worried about making things
complex. Only thing that might have some logic IMHO is of C++ relation. C#
is more in the class of C/C++. But yes that is right that having With is not
a big typing and readability benefit but still sometimes when setting tons
of properties it might have been easy, but ctrl + v works just fine.

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:ul**************@TK2MSFTNGP11.phx.gbl...

I disagree with the statement that it would be a nice addition to the
language. Check out the following "ask a designer" section on the MS
website for more information on why it was left out:

http://msdn.microsoft.com/vcsharp/pr...t/default.aspx

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Pohihihi" <no*****@hotmail.com> wrote in message
news:ec*************@TK2MSFTNGP10.phx.gbl...

'With' is a statement in VB. It would have been a nice addition to C# but
it is not so for now. You have to fully qualify Object.Proporties in C#

http://msdn.microsoft.com/library/de...rdsptozvba.asp
http://msdn.microsoft.com/library/de...eywords_pg.asp


"abc my vclass" <my********@myclass.com> wrote in message
news:e6**************@TK2MSFTNGP11.phx.gbl...

C# has VB's "with" command?

I like VB's with command, why don't know C# has it or not?

[seani]

LOL, couldn't agree more.

If syntactical simplicity and consistency was one of the aims of C#, it
fails miserably in that regard. The new C# 2.0 and generics will make this
even worse IMO.

I agree that the addition of "with" would add substantial readability
benefits; removing a complex common prefix on a reference shifts the
"focus" onto the reference in question.

You could argue that the same
benefit can be realised by functional decomposition, or by use of
temporary variable as a method of shortening the reference. Fair enough in
some cases, but peppering your code with temporary vars introduces "noise"
and functional decomposition to avoid clumsy reference expressions
can interrupt the visual "flow" of an algorithm and, well, it just feels
wrong.

Reasons given on the link are actually no better than "I want it cause it is
easy for me to work like that". MS was never worried about making things
complex. Only thing that might have some logic IMHO is of C++ relation. C#
is more in the class of C/C++. But yes that is right that having With is not
a big typing and readability benefit but still sometimes when setting tons
of properties it might have been easy, but ctrl + v works just fine.

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:ul**************@TK2MSFTNGP11.phx.gbl...

I disagree with the statement that it would be a nice addition to the
language. Check out the following "ask a designer" section on the MS
website for more information on why it was left out:

http://msdn.microsoft.com/vcsharp/pr...t/default.aspx

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Pohihihi" <no*****@hotmail.com> wrote in message
news:ec*************@TK2MSFTNGP10.phx.gbl...

'With' is a statement in VB. It would have been a nice addition to C# but
it is not so for now. You have to fully qualify Object.Proporties in C#

http://msdn.microsoft.com/library/de...rdsptozvba.asp
http://msdn.microsoft.com/library/de...eywords_pg.asp


"abc my vclass" <my********@myclass.com> wrote in message
news:e6**************@TK2MSFTNGP11.phx.gbl...
C# has VB's "with" command?

I like VB's with command, why don't know C# has it or not?

[Bruce Wood]

> If syntactical simplicity and consistency was one of the aims of C#, it fails miserably in that regard.

"A critic is a legless man who teaches running."

Just where, exactly, do you think that C# is unnecessarily complex?
I've been programming for 20 years and I find it one of the best
languages I've used.

[seani]

On Mon, 26 Dec 2005 21:24:21 -0800, Bruce Wood wrote:

If syntactical simplicity and consistency was one of the aims of C#, it fails miserably in that regard.
"A critic is a legless man who teaches running."

"A fanboi is a clueless man who preaches dogma"

There you go, one sneering quotation each. I can go all day if you like,
but I'd rather call it quits; you could, easily, have asked the question
without the implied insult.
Just where, exactly, do you think that C# is unnecessarily complex?
I've been programming for 20 years and I find it one of the best
languages I've used.

And I've been programming for <thinks> 17 years. I reckon I've used
<thinks> 9 languages in anger on fairly large, complex projects, another
handful of built-in scripting languages, and written half-a-dozen or so
mini-languages myself when the problem domain demanded it.

In terms of simplicity and consistency, the C# *language* falls below
average on my scale.

Before getting into the details, why do *you* hold the opinion that the
language is elegant?

Honestly, without wanting to make an argument out of things, what is it
that you consider makes it "one of the best"?

[Bruce Wood]

> Before getting into the details, why do *you* hold the opinion that the language is elegant?

I didn't say that it was elegant. I took issue with the statement that
it wasn't simple.

I've used plenty of arguably simpler languages, but with that
"simplicity" and "elegance" came the unfortunate requirement that
programmers take care of all the picky details. C++, for example, was
pretty bad in this regard. I'm not knocking the language: Stroustrup
did an excellent job and, I think, achieved his goals. It's also the
language I would recommend for certain types of high-performance and
real-time work. However, I've watched time and time again as average
programmers struggle to create reasonable complex software that's not
problem-ridden.

C#, for its supposed lack of simplicity, seems to me to strike an
excellent balance between being a workhorse like C / C++, taking care
of the messy details like Java, and being usable by average mortals. I
suppose that one could argue that VB.NET is more accessible than C#,
but IMHO VB encourages a sort of sloppiness that causes more problems
than it solves.

I'm a practical guy and I like working solutions to real problems. C#,
for my money, delivers, and no, I don't find it overly complex. VB.NET
is overly complex in that it does too much stuff behind your back. C++
is complex in anther way in that it requires you to take care of too
many picky housekeeping details.

I think that C# gets the balance right, that's all.

There you go, one sneering quotation each.

Sorry about the critic quote. It was intended to be light-hearted. I
guess I should have added a smiley afterward. :-)

[Frank Rizzo]

Bruce Wood wrote:

If syntactical simplicity and consistency was one of the aims of C#, it fails miserably in that regard.

"A critic is a legless man who teaches running."

Just where, exactly, do you think that C# is unnecessarily complex?
I've been programming for 20 years and I find it one of the best
languages I've used.

I haven't been programming for 20 years (just 10), however, the C#
syntax to create an event is ridiculous. This is one area where vb wins
hands down. Consider this:

public class Client
public event FireThis()

public sub Stuff()
raiseevent FireThis()
end sub
end class

Now compare this approach to having to setup delegates, linking them to
events, etc...

[Gabriel Magaña]

All those who didn't see a language design pissing match raise your hands...

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:ul**************@TK2MSFTNGP11.phx.gbl...

I disagree with the statement that it would be a nice addition to the
language. Check out the following "ask a designer" section on the MS
website for more information on why it was left out:

http://msdn.microsoft.com/vcsharp/pr...t/default.aspx

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Pohihihi" <no*****@hotmail.com> wrote in message
news:ec*************@TK2MSFTNGP10.phx.gbl...

'With' is a statement in VB. It would have been a nice addition to C# but
it is not so for now. You have to fully qualify Object.Proporties in C#

http://msdn.microsoft.com/library/de...rdsptozvba.asp
http://msdn.microsoft.com/library/de...eywords_pg.asp


"abc my vclass" <my********@myclass.com> wrote in message
news:e6**************@TK2MSFTNGP11.phx.gbl...

C# has VB's "with" command?

I like VB's with command, why don't know C# has it or not?

[Jon Skeet [C# MVP]]

Frank Rizzo <no**@none.com> wrote:

<snip>

I haven't been programming for 20 years (just 10), however, the C#
syntax to create an event is ridiculous. This is one area where vb wins
hands down. Consider this:

public class Client
public event FireThis()

public sub Stuff()
raiseevent FireThis()
end sub
end class

Now compare this approach to having to setup delegates, linking them to
events, etc...

Well, the code you've shown hasn't actually shown the wiring of the
events in the VB.

You need to separate three different elements:

1) Declaring the event
2) Subscribing/unsubscribing to the event
3) Firing the event

Let's look at each in turn:

1) Declaring the event

VB.NET allows you to create an event without explicitly declaring a
delegate. However, I can't see how that's a good idea really - clients
in other languages will need to know what type of delegate to use,
preferably with documentation. In other words, VB.NET is encouraging
what I consider to be sloppy programming.

Both C# and VB.NET allow you to provide your own add/remove semantics.
VB.NET also allows you to provide your own event raising semantics - it
would be nice if C# allowed this. I had to look pretty hard to find
this in the VB.NET docs though (most pages just showed the "simple"
event declaration syntax).

2) Subscribing/unsubscribing to the event

VB.NET has the "Handles" keyword, which autowires an event to a field,
by turning that field into a property internally. Personally, I have no
problem with wiring the event manually, and think it shows what's going
on more clearly - *without* implicitly changing fields into properties.

3) Firing the event

Here, VB.NET has RaiseEvent which appears not to be thread-safe (given
a brief look at it). It could raise a NullReferenceException if the
last subscriber unsubscribed between the nullity test and the

You can also call the event handler directly, using the event name
followed by "Event" (is that documented?) which means you can write
your own event firing code to make it thread-safe. I doubt that many
people bother though :(

In C# you have to do the nullity check yourself. This is a bit of a
pain I'll admit, but it does make it more straightforward to make the
code thread-safe.
If I understand you correctly, you prefer:
1) The fact that you don't need to specify the delegate in VB.NET. This
makes for code which is less clear for other languages IMO, as well as
for places where you need to explicitly add and remove handlers (you
have to use the implicitly created FooEventHandler delegate - and if
you've got lots of events using the same parameters, you'll end up with
multiple delegates for no good reason).

2) Wiring up the events using "Handles". I don't like fields becoming
properties implicitly. I may be in the minority on this one though.

So for me, C# wins. It's all a matter of preference...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[seani]

On Tue, 27 Dec 2005 16:16:10 -0800, Bruce Wood wrote:

Before getting into the details, why do *you* hold the opinion that the language is elegant?
I didn't say that it was elegant. I took issue with the statement that
it wasn't simple.

The language has 70-odd keywords, currently 2 different syntaxes (main
code and attribute definition; you can't use keyword assignment, except in
attribute definition - where you can - any *logic* to that?), soon to be 3
with the inclusion of generics. And 4 if you include lambda expressions
(in 3.0 IIRC). What a dog's dinner.

Clumsy syntax and declarations; MyObjectType myObject = new MyObjectType()
- yechh - pointless. Simplified in 2.0 (or is it 3.0?), but why did this
abomination exist in the first place?

etc. etc.

The argument I usually get from supporters is that there's a framework
method that will allow them to get the job done in 4 or 5 lines, and this
is pointed to as evidence that you can arrive at a "simple" solution. It's
finding them that's the trouble, and I find that for non-trivial
applications, they look like real bitches written down, practically
obfuscated. Admittedly, you get code completion, integrated help etc., but
this hardly points to simplicity.
I've used plenty of arguably simpler languages, but with that
"simplicity" and "elegance" came the unfortunate requirement that
programmers take care of all the picky details. C++, for example, was
pretty bad in this regard. I'm not knocking the language: Stroustrup
did an excellent job and, I think, achieved his goals. It's also the
language I would recommend for certain types of high-performance and
real-time work. However, I've watched time and time again as average
programmers struggle to create reasonable complex software that's not
problem-ridden.
Yes, but "achieved" is the keyword here. We are several decades and
several orders of magnitude in terms of processing power down the line.
I'd have less of a problem accepting that C# is an advance over C++
(except perhaps that it's abandoned MI), a language that's been knocking
about for nigh on 20 years, but I hardly think that's cause for
celebration.

This is a greenfield language, no legacy compatibility issues. It's far
less impressive when viewed in that light. It's strikes me as a series of
improvements on the somewhat shaky bedrock of typical "curly brace"
languages. Disappointing.

C#, for its supposed lack of simplicity, seems to me to strike an
excellent balance between being a workhorse like C / C++, taking care
of the messy details like Java, and being usable by average mortals. I
suppose that one could argue that VB.NET is more accessible than C#,
but IMHO VB encourages a sort of sloppiness that causes more problems
than it solves.

I'm with you on VB/VBScript/VB.NET; bloody awful IMHO.
I'm a practical guy and I like working solutions to real problems. C#,
for my money, delivers, and no, I don't find it overly complex. VB.NET
is overly complex in that it does too much stuff behind your back. C++
is complex in anther way in that it requires you to take care of too
many picky housekeeping details.
Agreed, buy I just don't accept that when you abstract away all of the
irritating and error-prone housekeeping associated with the likes of C++,
you have to end up with a compromise like C#

If you look at the specs. for 2.0 and 3.0, you can see features being
bolted on left, right and centre. It all just looks like an afterthought,
as if there's no design philosophy behind it, just knee-jerk
reaction to the latest fashionable practise.

I think that C# gets the balance right, that's all.

There you go, one sneering quotation each.

Sorry about the critic quote. It was intended to be light-hearted. I
guess I should have added a smiley afterward. :-)

LOL, I did take the bait a bit hard :) But I would say I have a perfect
right to criticise the language *without* being a language designer; I
can't play a musical instrument, but that doesn't disqualify or invalidate
my opinion as a listener.

[Frank Rizzo]

Jon Skeet [C# MVP] wrote:

Frank Rizzo <no**@none.com> wrote:

<snip>

I haven't been programming for 20 years (just 10), however, the C#
syntax to create an event is ridiculous. This is one area where vb wins
hands down. Consider this:

public class Client
public event FireThis()

public sub Stuff()
raiseevent FireThis()
end sub
end class

Now compare this approach to having to setup delegates, linking them to
events, etc...

Well, the code you've shown hasn't actually shown the wiring of the
events in the VB.

You need to separate three different elements:

1) Declaring the event
2) Subscribing/unsubscribing to the event
3) Firing the event

Let's look at each in turn:

1) Declaring the event

VB.NET allows you to create an event without explicitly declaring a
delegate. However, I can't see how that's a good idea really - clients
in other languages will need to know what type of delegate to use,
preferably with documentation. In other words, VB.NET is encouraging
what I consider to be sloppy programming.

Both C# and VB.NET allow you to provide your own add/remove semantics.
VB.NET also allows you to provide your own event raising semantics - it
would be nice if C# allowed this. I had to look pretty hard to find
this in the VB.NET docs though (most pages just showed the "simple"
event declaration syntax).

I use events in a vb-authored DLL in c# every single day. Never really
had any problems with not knowing what parameters do. I do agree that
it could be an issue with 3rd party DLLs, however, you can always fall
back to the delegate way of doing things in VB.
2) Subscribing/unsubscribing to the event

VB.NET has the "Handles" keyword, which autowires an event to a field,
by turning that field into a property internally. Personally, I have no
problem with wiring the event manually, and think it shows what's going
on more clearly - *without* implicitly changing fields into properties.

3) Firing the event

Here, VB.NET has RaiseEvent which appears not to be thread-safe (given
a brief look at it). It could raise a NullReferenceException if the
last subscriber unsubscribed between the nullity test and the
No, it can't. I'd like to see you reproduce this.
Secondly, don't use events as a way to marshal between threads. This
ain't delphi.
You can also call the event handler directly, using the event name
followed by "Event" (is that documented?) which means you can write
your own event firing code to make it thread-safe. I doubt that many
people bother though :(
In C# you have to do the nullity check yourself. This is a bit of a
pain I'll admit, but it does make it more straightforward to make the
code thread-safe.
That part of C# is clean. I am talking about wiring an event, not
raising it.
If I understand you correctly, you prefer:
1) The fact that you don't need to specify the delegate in VB.NET. This
makes for code which is less clear for other languages IMO, as well as
for places where you need to explicitly add and remove handlers (you
have to use the implicitly created FooEventHandler delegate - and if
you've got lots of events using the same parameters, you'll end up with
multiple delegates for no good reason).

2) Wiring up the events using "Handles". I don't like fields becoming
properties implicitly. I may be in the minority on this one though.
I am not understanding what you mean by fields becoming properties. You
use Handles on a method, not a field.

So for me, C# wins. It's all a matter of preference...
yep.

[Jon Skeet [C# MVP]]

Frank Rizzo <no**@none.com> wrote:

3) Firing the event

Here, VB.NET has RaiseEvent which appears not to be thread-safe (given
a brief look at it). It could raise a NullReferenceException if the
last subscriber unsubscribed between the nullity test and the
No, it can't.

Have you looked at the IL produced by RaiseEvent? It's equivalent to
the C# code:

if (myEvent != null)
{
myEvent (parameters);
}

Can you spot the race condition?
I'd like to see you reproduce this.
You'd need to be unlucky to see it - you'd have to get a thread context
switch between the test for nullity and the call. However, the
folllowing program does it for me, after a while.

Imports System
Imports System.Threading

Class Test

Shared Event Foo()

Shared Sub Main()
Dim t as New Thread(new ThreadStart(AddressOf OtherThread))
t.Start()
While True
RaiseEvent Foo()
End While
End Sub

Shared Sub OtherThread()
While True
AddHandler Foo, AddressOf NoOp
RemoveHandler Foo, AddressOf NoOp
End While
End Sub

Shared Sub NoOp()
End Sub

End Class
Secondly, don't use events as a way to marshal between threads. This
ain't delphi.

I wasn't talking about events marshalling between threads. I was
talking about events being subscribed to and unsubscribed from
different threads.

2) Wiring up the events using "Handles". I don't like fields becoming
properties implicitly. I may be in the minority on this one though.

I am not understanding what you mean by fields becoming properties. You
use Handles on a method, not a field.

Well, it's Handles/WithEvents - you can only (AFAIK) use "Handles" on a
field which is declared "WithEvents". Declaring a field as being
"WithEvents" silently turns it into a field (so that when the value is
changed, everything gets unsubscribed from the old value and
resubscribed with the new value).

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

The language has 70-odd keywords, currently 2 different syntaxes (main
code and attribute definition; you can't use keyword assignment, except in
attribute definition - where you can - any *logic* to that?)
Can you explain further this?
soon to be 3
with the inclusion of generics. And 4 if you include lambda expressions
(in 3.0 IIRC). What a dog's dinner.
You are right, with the inclusion of generics & lambda expressions the
language will not be simple to read , or not as simpler at least, Right now
if you know c/c++ , java, javascript, php ? or IMO if you have a knowledge
outside VB you can read C# without much problems, with those inclussion that
will not be the case anymore.
Time will tell if these features were a good idea or not, right now they
seems like a very good one.
Clumsy syntax and declarations; MyObjectType myObject = new MyObjectType()
- yechh - pointless. Simplified in 2.0 (or is it 3.0?), but why did this
abomination exist in the first place?
I don't think the above is clumsy, quite the opposite I find it natural. or
maybe (if I get cynical) tradicional, it's easier to read both to me and
the compiler , you used the simpler one, what about :
MyObjectType myObject = GuessWhatThisMethodReturn()

I do know from looking at it that GuessWhatThisMethodReturn returns a
MyObjectType (or one derived class ).
Now, you are talking about the "implicit declaration" (not sure if this is
the correct term though) that will be in 3.0 , you declare a variable as
"var" and the variable will take the type that the right side expression
has. Note that you can ONLY use this if you assign the variable at the same
time that you declare it.

Personally I do not like it to be used in escenarios as the above, it may
have two consequences IMO:

1- Harder to read code , in the current form with only seen that line you
know the type of myObject , if using "var" you cannot, you have to go to the
definition of GuessWhatThisMethodReturn to find out

2- It will look that the typing got relaxed (the VB crow will be salivating
with this) no need to declare the precise type, just declare it as var and
it will get assigned no matter what. you bet you will see instances where
all the variables are declared as var, later at compile time the problems
will come ( cause it's strong typed as always has been ) .

The argument I usually get from supporters is that there's a framework
method that will allow them to get the job done in 4 or 5 lines, and this
is pointed to as evidence that you can arrive at a "simple" solution. It's
finding them that's the trouble, and I find that for non-trivial
applications, they look like real bitches written down, practically
obfuscated. Admittedly, you get code completion, integrated help etc., but
this hardly points to simplicity.
How different is a non-trivial app written in c# from one written in C++ or
Java?


This is a greenfield language, no legacy compatibility issues. It's far
less impressive when viewed in that light. It's strikes me as a series of
improvements on the somewhat shaky bedrock of typical "curly brace"
languages. Disappointing.
Well there are a lot of experimental (read differents) languages for you to
choose from. But if what you are looking for is a general type of language,
one that you hope massive amount of people to use you cannot change that
much ! , the same thing happened with Java, it was the same escenario, what
they did, well the same that MS did now.

C#, for its supposed lack of simplicity, seems to me to strike an
excellent balance between being a workhorse like C / C++, taking care
of the messy details like Java, and being usable by average mortals. I
suppose that one could argue that VB.NET is more accessible than C#,
but IMHO VB encourages a sort of sloppiness that causes more problems
than it solves.

Totally agreed !
I'm with you on VB/VBScript/VB.NET; bloody awful IMHO.

Yes, but it has his place in the marketplace, a very succesful one IMO.
Did anybody really programmed web apps in C++ ?
I did A LOT of programming in VBScript back in the days, it was the way to
go if you were in a MS platform ( or with MS tools )

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Now compare this approach to having to setup delegates, linking them to
events, etc...

Personally I do not find that so complex, or no complex at all to tell you
the true. It's very logical and all you have to do is follow it. You declare
the delegate , you create an instance of it , you assign it and when needed
you just access it.

What is wrong with that?


--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

[Søren Reinke]

>

Clumsy syntax and declarations; MyObjectType myObject = new MyObjectType()
- yechh - pointless. Simplified in 2.0 (or is it 3.0?), but why did this
abomination exist in the first place?

Whats clumsy about this ?

The syntax is logical, and makes sense

/Søren Reinke