A
abc my vclass
C# has VB's "with" command?
I like VB's with command, why don't know C# has it or not?
I like VB's with command, why don't know C# has it or not?
P
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/default.asp?url=/library/en-us/vblr7/html/vaorikeywordsptozvba.asp
http://msdn.microsoft.com/library/d...y/en-us/csref/html/vclrfcsharpkeywords_pg.asp
is not so for now. You have to fully qualify Object.Proporties in C#
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vblr7/html/vaorikeywordsptozvba.asp
http://msdn.microsoft.com/library/d...y/en-us/csref/html/vclrfcsharpkeywords_pg.asp
N
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/programming/language/ask/withstatement/default.aspx
Hope this helps.
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/programming/language/ask/withstatement/default.aspx
Hope this helps.
P
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.
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 said:
S
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.
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.
B
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.
"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.
S
seani
"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.
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"?
B
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.
Sorry about the critic quote. It was intended to be light-hearted. I
guess I should have added a smiley afterward.
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.
Sorry about the critic quote. It was intended to be light-hearted. I
guess I should have added a smiley afterward.
F
Frank Rizzo
Bruce said:
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...
G
Gabriel Magaña
All those who didn't see a language design pissing match raise your hands...
Nicholas Paldino said:
J
Jon Skeet [C# MVP]
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...
S
seani
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.
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.
I'm with you on VB/VBScript/VB.NET; bloody awful IMHO.
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.
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 perfectright 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.
F
Frank Rizzo
Jon said:
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.
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.
I am not understanding what you mean by fields becoming properties. You
use Handles on a method, not a field.
J
Jon Skeet [C# MVP]
Frank Rizzo said:
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?
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
I wasn't talking about events marshalling between threads. I was
talking about events being subscribed to and unsubscribed from
different threads.
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).
I
Ignacio Machin \( .NET/ C# MVP \)
Hi,
Can you explain further this?
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.
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 ) .
How different is a non-trivial app written in c# from one written in C++ or
Java?
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.
Totally agreed !
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 )
Can you explain further this?
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.
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 ) .
How different is a non-trivial app written in c# from one written in C++ or
Java?
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.
Totally agreed !
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 )
I
Ignacio Machin \( .NET/ C# MVP \)
Hi,
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?
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?
S
Søren Reinke
Whats clumsy about this ?
The syntax is logical, and makes sense
/Søren Reinke