Cor Ligthert said:
Daniel,
Can you prove what you write about the performance facts and not showing
that as Daniel nicely described on one or the other Blog page. Proving it
showing a Microsoft page is as well a good prove in my opinion.
Well, here is the set method for a WithEvents variable which handles (It
transforms the variable into a property). This is unoptimized because I
don't care enough to do too much.
..method private specialname static void set_c(class
[System.Windows.Forms]System.Windows.Forms.Control WithEventsValue) cil
managed synchronized
{
.custom instance void
[mscorlib]System.Diagnostics.DebuggerNonUserCodeAttribute::.ctor() = ( 01 00
00 00 )
// Code size 72 (0x48)
.maxstack 3
IL_0000: ldsfld class
[System.Windows.Forms]System.Windows.Forms.Control
WithEventsTest.Module1::_c
IL_0005: nop
IL_0006: brfalse.s IL_001f
IL_0008: ldsfld class
[System.Windows.Forms]System.Windows.Forms.Control
WithEventsTest.Module1::_c
IL_000d: ldnull
IL_000e: ldftn void WithEventsTest.Module1::Test(object,
class
[mscorlib]System.EventArgs)
IL_0014: newobj instance void
[mscorlib]System.EventHandler::.ctor(object,
native
int)
IL_0019: callvirt instance void
[System.Windows.Forms]System.Windows.Forms.Control::remove_Click(class
[mscorlib]System.EventHandler)
IL_001e: nop
IL_001f: nop
IL_0020: ldarg.0
IL_0021: stsfld class
[System.Windows.Forms]System.Windows.Forms.Control
WithEventsTest.Module1::_c
IL_0026: ldsfld class
[System.Windows.Forms]System.Windows.Forms.Control
WithEventsTest.Module1::_c
IL_002b: nop
IL_002c: brfalse.s IL_0045
IL_002e: ldsfld class
[System.Windows.Forms]System.Windows.Forms.Control
WithEventsTest.Module1::_c
IL_0033: ldnull
IL_0034: ldftn void WithEventsTest.Module1::Test(object,
class
[mscorlib]System.EventArgs)
IL_003a: newobj instance void
[mscorlib]System.EventHandler::.ctor(object,
native
int)
IL_003f: callvirt instance void
[System.Windows.Forms]System.Windows.Forms.Control::add_Click(class
[mscorlib]System.EventHandler)
IL_0044: nop
IL_0045: nop
IL_0046: nop
IL_0047: ret
}
It makes life easier for VB devs, it allows for better RAD features(the
handles clause), but it transforms simple field assignment into a property
with a fairly large set method. That *will* affect performance negativly. It
is, however, unlikely to matter much.
However, in my and a lot others opinion is the big advantage from VBNet
the
IDE.
It helps you to take the right words and the right spelling of those. To
show you that with one however not the only example.
I know. And the VB ide irks me to no end. I don't like IDE's that do things
that I don't want them to. Adding semicolons where it *thinks* I need one or
trying to suggest a different spelling for a word is absolutly *wrong* in an
IDE as far as I'm concerned, but I have no particular problem with people
who like that, I just don't want it myself
Although VBNet is based on the English language are that some few very
simple basic words or created words as "OrElse".
The IDE helps people to show the simple mistakes especially when option
Strict is ON.
Do not forget that only 8% of the world is using English and .Net is
completely based on English. I always have the idea that a lot of people
forget that.
I don't forget it, but you must remember that most(probably all) of the
framework authors speak english, and english is the defacto standard for
languages. I mean, look at ruby. That was written by a japanese guy(Yukihiro
Matsumoto, best I can tell he's a japanese native), but it is still
primarily in english. If you write a langauge that *isn't* in english, you
are simply not going to do well as pretty close to 100% of the developer
community atleast knows enough english to handle programming languages(if,
while, long, int, Int32, etc are not exactly unique to C# after all) while a
very small portion is likely to know whatever language you choose to design
your library in. Some English is pretty close to a requirement for
programming, I dunno if thats a good thing or not, and I'm sure it can be
debated endlessly, but a single standard langauge is certainly a good thing,
IMHO.
I've even seen it suggested that code should be written strictly in English,
no matter what your native language is, but I don't personally have any
particular opinions on that.
When that IDE from C# was the same as it is in VBNet and did as well
adding
forgotten however needed ; and () and things like that, than the choose
for
me would probably go to C#, because it would than even be more natural
language independent and less characters to type.
Again, inserting characters is bad mojo, LOL.
(Although I would like to have those strong convert functions from VBNet
as
well)
I want better conversion functions, but C#'s conversion operator is
perfectly strong(its as strong as they come really), just less pervasive and
unpleasent. They just use that utterly nasty casting syntax the designers
settled on. Casting and converting is probably the ugliest thing about C#.
Casting and conversion should *not* have used the same operator and they
should not have fallen into the C\Java casting trap.
Personally I would like to see
convert<type>(<expression>)
and
cast<type>(<expression>)
instead. Perhaps shortcuts like
MyObject x = cast(<expression>)
so that the type doesn't have to be duplicated when the type is already
apparent(I don't think I'd like it in a method call or whatnot, but in a
variable declaration its not so bad).
