Not to start a flame war, but...

[Frank Rizzo]

Not to start a flame war, but…

I’ve been programming mostly in C# for the last couple of months, but I
am quickly becoming more and more aggravated with it. My reasons are
below, but I was wondering what other people’s experiences are. I am
thinking that I’ll probably switch to vb.net in the whidbey time frame,
if things don’t change.

Reasons:
1. Why is there no intellisense after I type an enum data type followed
by the = sign? Why do I have to type the type of the enum + “.” to get
the intellisense. I had a habit of giving enums verbose names (to make
the code self-documenting) and this habit is causing me to type one hell
of a lot more than I want to. Example:

this.WindowState = … where in the world is the intellisense. I have to
type the following to get it:
this.WindowState = FormWindowState.

This is ridiculous.

2. Insane amount of silly conversions and casts.

int x;
x = FormWindowState.Normal; //this will not compile
x = (int) FormWindowState.Normal; //this compiles

Why in the world do I need to cast FormWindowState.Normal to an int, if
it is already an integer anyway? Shouldn’t this be resolved at the
compile time? I understand that someone @MS went and won the language
features jihad, but this just translates into lost productivity. VB
(-option strict) resolves this very nicely, I’ve never had a problem.

3. For WinForm apps, in the Code View for the form, it is impossible to
quickly find out which events are available for an object (like a button
or checkbox or whatever). You have to switch to Form View, go to
properties, switch to Events and then you’ll see it. Why such insanity?
Why not just copy the vb.net approach. The vb.net team is only one
floor away, just go and ask them for it.

There are other gripes, but I am just too tired.

 

[Jon Skeet [C# MVP]]

Not to start a flame war, but?

I?ve been programming mostly in C# for the last couple of months, but I
am quickly becoming more and more aggravated with it. My reasons are
below, but I was wondering what other people?s experiences are. I am
thinking that I?ll probably switch to vb.net in the whidbey time frame,
if things don?t change.

Reasons:
1. Why is there no intellisense after I type an enum data type followed
by the = sign? Why do I have to type the type of the enum + ?.? to get
the intellisense. I had a habit of giving enums verbose names (to make
the code self-documenting) and this habit is causing me to type one hell
of a lot more than I want to. Example:

this.WindowState = ? where in the world is the intellisense. I have to
type the following to get it:
this.WindowState = FormWindowState.

This is ridiculous.

I believe this has improved in Whidbey, but personally I've never had
that much of a problem with it anyway. Don't forget that you can still
get intellisense on the name of the enum too, e.g. press F and then
Ctrl-Space to get up a list of things which you can whittle down to
FormWindowState without having to type in the whole thing.

2. Insane amount of silly conversions and casts.

int x;
x = FormWindowState.Normal; //this will not compile
x = (int) FormWindowState.Normal; //this compiles

Why in the world do I need to cast FormWindowState.Normal to an int, if
it is already an integer anyway? Shouldn?t this be resolved at the
compile time? I understand that someone @MS went and won the language
features jihad, but this just translates into lost productivity. VB
(-option strict) resolves this very nicely, I?ve never had a problem.

FormWindowState *isn't* an int though. It's an enum *based* on an int,
but it isn't an int itself. This is just C# being strict about its
typing, which again I think it fine.

3. For WinForm apps, in the Code View for the form, it is impossible to
quickly find out which events are available for an object (like a button
or checkbox or whatever). You have to switch to Form View, go to
properties, switch to Events and then you?ll see it. Why such insanity?
Why not just copy the vb.net approach. The vb.net team is only one
floor away, just go and ask them for it.

Personally I don't use the forms designer anyway, so I'd probably have
a separate method solely for setting up the events if I were
particularly worried about that. You can always open up the code that
the designer has generated for you and find the event handler anyway.

 

[Erik Frey]

The three items you've listed are personal preferences, and pretty
indicative of the mentality of someone coming from a VB world (not meant as
a dig - just the truth).

Actually, I'll give you item #1 - the lack of enum intellisense can be
annoying. But I guess this has been adressed.

In any case, this is exactly why you have the option to use VB or C#.

Erik

 

[Rob Teixeira [MVP]]

Not to start a flame war, but…
[snip]

Why in the world do I need to cast FormWindowState.Normal to an int, if
it is already an integer anyway? Shouldn’t this be resolved at the
compile time? I understand that someone @MS went and won the language
features jihad, but this just translates into lost productivity. VB
(-option strict) resolves this very nicely, I’ve never had a problem.

Even with Option Strict On, VB will accept this assignment. VB will reject
assignments based on narrowing/widening rules - for example, implicit
assignment from Double to Integer are not allowed with Option Strict On.
However, in this case, you are correct. The enum is just a "set" (in other
languages' terminology) of Integer (by default) values, and one of the
values of that set (which translates into a literal field) is in fact an
Integer. Therefore, a perfectly legal assignment. However, from an overly
strict type purist point of view, which is the C#'s phylosophy, the compiler
requires the cast as an "are you sure you really want to do this" assertion.

3. For WinForm apps, in the Code View for the form, it is impossible to
quickly find out which events are available for an object (like a button
or checkbox or whatever). You have to switch to Form View, go to
properties, switch to Events and then you’ll see it. Why such insanity?
Why not just copy the vb.net approach.

This is being addressed to some degree in the next release.

The vb.net team is only one
floor away, just go and ask them for it.

There are other gripes, but I am just too tired.

Well, I use both languages frequently. Which one I use is dictated by the
client. There are little quirks I don't like about either. Overall, the .NET
infrastructure and both languages are my favorite environments to work
in/with. I view both languages as equally capable, but if the most important
criteria for you is the syntactically-less-anal language, then I suggest
sticking with VB. It's one of the few things that distinguishes the two,
especially after the next release, and it's more a matter of preference than
anything else.
Some of the points you made in your gripe were very specific design goals
for C#, so I doubt you will be happy with it. It's not as if the C# team
dropped the ball and forgot some of this stuff - it was specifically
intended as part of the language design.

-Rob Teixeira [MVP]

 

[Jon Skeet [C# MVP]]

Even with Option Strict On, VB will accept this assignment. VB will reject
assignments based on narrowing/widening rules - for example, implicit
assignment from Double to Integer are not allowed with Option Strict On.
However, in this case, you are correct. The enum is just a "set" (in other
languages' terminology) of Integer (by default) values, and one of the
values of that set (which translates into a literal field) is in fact an
Integer.

No - the type of each field is an instance of the enum, but it has an
integer value associated with it. That's why if you do
EnumName.Foo.GetType() you'll get EnumName, not Int32.

A value type value itself in IL doesn't have any actual type - it gets
the type from the stack information. For instance:

using System;
using System.IO;

public class Test
{
static void Main()
{
FileMode fm = FileMode.Append;
int i = (int)fm;
}
}

compiles to (Main method only):

..method private hidebysig static void Main() cil managed
{
.entrypoint
// Code size 5 (0x5)
.maxstack 1
.locals init (valuetype [mscorlib]System.IO.FileMode V_0,
int32 V_1)
IL_0000: ldc.i4.6
IL_0001: stloc.0
IL_0002: ldloc.0
IL_0003: stloc.1
IL_0004: ret
} // end of method Test::Main

The type of slot 0 is FileMode, but the type of slot 1 is Int32. They
can both have the same value, but the type of the expression
FileMode.Append *is* a FileMode, not an int.

This is being addressed to some degree in the next release.

Oo, haven't heard about that - could you tell me more?

 

[Rob Teixeira [MVP]]

No - the type of each field is an instance of the enum, but it has an
integer value associated with it. That's why if you do
EnumName.Foo.GetType() you'll get EnumName, not Int32.

A value type value itself in IL doesn't have any actual type - it gets
the type from the stack information. For instance:

Well, we can go in circles about this
As you say, the actual value of the instance is in fact a 32-bit (Int32)
value, unless you change the base element type (that should be evidence of
another clue right there) for the enum in question.
By the Value Type association, it's typed to the specific derrived enum
typed, but as most Enumeration systems in most other languges, the base
element type is a simple integral number (of some width).
I don't believe there's a clear-cut way of saying it's one and not the
other. You can certainly argue both ways.
From the purist strict type point of view (which is what C# is portraying
here), you have the benefit of the compiler trying to catch something like
an assignment of WindowState.Maximized to a FileMode varaiable. Even VB with
option strict on will catch that little bugger. But it's still a literal
32-bit integral value under the covers.

Oo, haven't heard about that - could you tell me more?

Actually, I'm a bit sorry to have brought this one up. I hesitate to mention
anything covered under the NDA that I haven't seen published anywhere else.
Especially since I believe some of the IDE features aren't cast in stone yet
(at least from what I can tell). I can say that I've seen some pretty decent
improvements in the class builder for both languages though, but beyond
that, we'll both have to wait. Sorry for the vagueness

-Rob Teixeira [MVP]

 

[Jon Skeet [C# MVP]]

Well, we can go in circles about this

Yeah, let's

As you say, the actual value of the instance is in fact a 32-bit (Int32)
value, unless you change the base element type (that should be evidence of
another clue right there) for the enum in question.

Yes - I was taking as read that for this example it was based on Int32.

By the Value Type association, it's typed to the specific derrived enum
typed, but as most Enumeration systems in most other languges, the base
element type is a simple integral number (of some width).

Base element type, yes. But the enumerated type doesn't *derive* from
Int32. (There's no derivation of value types.)

I don't believe there's a clear-cut way of saying it's one and not the
other. You can certainly argue both ways.
From the purist strict type point of view (which is what C# is portraying
here), you have the benefit of the compiler trying to catch something like
an assignment of WindowState.Maximized to a FileMode varaiable. Even VB with
option strict on will catch that little bugger. But it's still a literal
32-bit integral value under the covers.

Well, unless you take into account the type metadata, it's just a 32
bit value - as are floats and uints, too. What I'm trying to say is
that the actual value is just 32 bits, and the typing is provided by
the stack or the containing type (for an instance/static variable). The
type of the expression FileMode.Append is FileMode, *not* int. C#
defines the conversion from enum type to any integral type as an
explicit conversion, whereas VB.NET presumably defines it as an
implicit conversion. The reason you can't do
FileMode m = WindowState.Maximized is presumably that even VB.NET
doesn't define the conversion from enum to enum as implicit. Either
way, there *is* a conversion going on, even if it's just a logical one
(like uint to int or vice versa).

Actually, I'm a bit sorry to have brought this one up. I hesitate to mention
anything covered under the NDA that I haven't seen published anywhere else.
Especially since I believe some of the IDE features aren't cast in stone yet
(at least from what I can tell). I can say that I've seen some pretty decent
improvements in the class builder for both languages though, but beyond
that, we'll both have to wait. Sorry for the vagueness

No problem. I hope it's something in the language itself and not just
in the IDE.

 

[Rob Teixeira [MVP]]

No problem. I hope it's something in the language itself and not just
in the IDE.

Frank's original point #3 was about the droplist that shows the events
available for an object in code view - IOW, specifically an IDE feature.
On the other hand, if you are looking specifically for code-based
enhancements to events (or delegates in general), then Whidbey's "anonymous
methods" are something worth looking at. Nothing secret about that, as they
have let that cat out of the bag

-Rob Teixeira [MVP]

 

[Miha Markic]

Hi Jon,

I agree with you on first two points.

Personally I don't use the forms designer anyway, so I'd probably have
a separate method solely for setting up the events if I were
particularly worried about that. You can always open up the code that
the designer has generated for you and find the event handler anyway.

You don't use designer? Are you typing all the stuff or you don't do
winforms at all?

 

[Jon Skeet [C# MVP]]

I agree with you on first two points.


You don't use designer? Are you typing all the stuff or you don't do
winforms at all?

When I do a GUI (which is rarely, admittedly) I type the code in
myself. I use the designer occasionally just to get some ideas about
how to hook things up, but then for real code I write it by hand in
order to get more readable and maintainable code.

 

[Pete Davis]

[snip]

Reasons:
1. Why is there no intellisense after I type an enum data type followed
by the = sign? Why do I have to type the type of the enum + “.” to get
the intellisense. I had a habit of giving enums verbose names (to make
the code self-documenting) and this habit is causing me to type one hell
of a lot more than I want to. Example:

this.WindowState = … where in the world is the intellisense. I have to
type the following to get it:
this.WindowState = FormWindowState.

This is ridiculous.

Take a look at Visual Assist. It has improved intellisense. I find it
worthwhile for the intellisense improvements alone. But in the big scheme of
things, I find this to be a very minor annoyance at most and could hardly
justify changing languges over it.

2. Insane amount of silly conversions and casts.

int x;
x = FormWindowState.Normal; //this will not compile
x = (int) FormWindowState.Normal; //this compiles

Why in the world do I need to cast FormWindowState.Normal to an int, if
it is already an integer anyway? Shouldn’t this be resolved at the
compile time? I understand that someone @MS went and won the language
features jihad, but this just translates into lost productivity. VB
(-option strict) resolves this very nicely, I’ve never had a problem.

This isn't a problem, this is a feature. I can't count how many times I had
unintended conversions in C++ that took forever to track down. I like the
fact that C# makes me acknowledge any conversions by explicitly casting
them. I think it improves productivity myself.

3. For WinForm apps, in the Code View for the form, it is impossible to
quickly find out which events are available for an object (like a button
or checkbox or whatever). You have to switch to Form View, go to
properties, switch to Events and then you’ll see it. Why such insanity?
Why not just copy the vb.net approach. The vb.net team is only one
floor away, just go and ask them for it.

I use regions to group control events separately from the rest of my code. I
find this quite effective and if, for example, I have a grid control with a
number of events, I might assign it a region by itself. I've never had a
problem finding my code because of the ability to define regions. Something
I never knew I needed.

Pete

 

[Christoph Nahr]

You don't use designer? Are you typing all the stuff or you don't do
winforms at all?

I don't use the designer either. Windows.Forms lets me do nearly
everything I want to do with so few lines that using a designer, and
then manually enhancing the code, doesn't seem worth the time.

 

[Miha Markic]

Hi Christoph,

Gee guys - you are almost Don Boxed.
Have you ever tried creating a form with a complex datagrid, and lots of
controls (not that much to choke it of course) on it?
How do you position them - try/modify/try/...?

 

[Christoph Nahr]

Gee guys - you are almost Don Boxed.

Actually, my idol is Charles Petzold. He never liked MFC, just like
me!

Have you ever tried creating a form with a complex datagrid, and lots of
controls (not that much to choke it of course) on it?
How do you position them - try/modify/try/...?

I've written a few utility routines for repetitive UI tasks, among
them one that sets the font and gives me em and en values (i.e.
FontHeight and 1/2 of that). Then I simply size & position every
control in terms of em and en.

I have some typographical knowledge so I'm pretty good at predicting
how a dialog will look. I don't know what you would consider complex
-- I generally use tabs before a dialog would become overloaded -- but
I do have ten or more controls on a single tab page quite often.

Sure I'll have to do some test runs but I actually found I'll arrive
at a good-looking dialog faster this way than if I had to point my
mouse at exactly the right position for each control. Besides, I
always hated mouse-driven layout... I just can't "paint" with a mouse
pointer! I'd rather plan the form on paper and then type in ems.

 

[Jon Skeet [C# MVP]]

I'd rather plan the form on paper and then type in ems.

That's the most important thing - planning on paper. A GUI which isn't
planned ahead of time will always look like it hasn't been planned
ahead of time.

Also, I can never get things "just right" with the forms designer...

(I miss Java's layout management though. It looks like things will be a
lot better in Longhorn, and I heard rumours there was going to be a lot
more stuff in Whidbey too...)

 

[Roy Fine]

Actually, my idol is Charles Petzold. He never liked MFC, just like
me!

HUH!! Better check your books mate - Petzold was a great fan of the dialog
resource editor!

roy fine

 

[Frank Rizzo]

That's the most important thing - planning on paper. A GUI which isn't
planned ahead of time will always look like it hasn't been planned
ahead of time.

Also, I can never get things "just right" with the forms designer...

Hell, forget c#, just go straight to MSIL, if you need that much
control. Compiler is just a silly code generator anyway.

 

[Christoph Nahr]

HUH!! Better check your books mate - Petzold was a great fan of the dialog
resource editor!

Really? What a disappointment. In his latest "Programming Windows with
C#" he does write out the code for all controls, though.

 

[Jon Skeet [C# MVP]]

Hell, forget c#, just go straight to MSIL, if you need that much
control. Compiler is just a silly code generator anyway.

C# allows me to express everything I want to in a readable,
maintainable form. The forms designer doesn't.

 

[Miha Markic]

Hi,

That's the most important thing - planning on paper. A GUI which isn't
planned ahead of time will always look like it hasn't been planned
ahead of time.

You can plan it on screen with forms designer, too