The syntax free feature of C# and VB.NET

[Jacky Luk]

I'm having a question... I have been programming for years with VS6, now
want to switch to the .NET languages, I know VB.NET is quite easy, but what
about C#? In C++, you have to remember a lot of "settings" before you get to
the "fruit" of the program, is that what the C# language is all about, the
advantage of forgetting about syntax like wndproc etc? However, I need to
transit my skills from C++/VB to C#/VB.NET which is a quite cumberstone and
tedious practice, could anyone provide some easier ways or reference sites
to convert the syntax from VS6 to VS.NET languages in a much more direct
way?
Thanks
Jack

 

[Jon Skeet [C# MVP]]

I'm having a question... I have been programming for years with VS6, now
want to switch to the .NET languages, I know VB.NET is quite easy, but what
about C#? In C++, you have to remember a lot of "settings" before you get to
the "fruit" of the program, is that what the C# language is all about, the
advantage of forgetting about syntax like wndproc etc? However, I need to
transit my skills from C++/VB to C#/VB.NET which is a quite cumberstone and
tedious practice, could anyone provide some easier ways or reference sites
to convert the syntax from VS6 to VS.NET languages in a much more direct
way?

C# is much simpler than C++ - and particularly much simpler the VC++
with all its extra macros etc.

Personally I think C# is a lovely language - it has some flaws, but in
general it's great.

Rather than try to convert syntax-for-syntax, I'd strongly advise
learning C# (or VB.NET) from scratch. That way you're more likely to
code in idiomatic C#, rather than C# which looks like it really wants
to be C++.

 

[Guest]

I'm having a question... I have been programming for years with VS6, now

want to switch to the .NET languages, I know VB.NET is quite easy, but what
about C#? In C++, you have to remember a lot of "settings" before you get to
the "fruit" of the program, is that what the C# language is all about, the
advantage of forgetting about syntax like wndproc etc? However, I need to
transit my skills from C++/VB to C#/VB.NET which is a quite cumberstone and
tedious practice

Yes, this is exactly what C# sets out to solve. It aims to give people RAD
capability (i.e., drag and drop a control on a form, double click it and you
magically get the cursor positioned in a routine which will execute on the
default event of the control, etc..) while also giving people the 'tightness'
(case-sensitive, all variables must be declared, no optional parameters,
etc.) that C/C++ developers associate with being comfortable about the way
their language operates.

, could anyone provide some easier ways or reference sites
to convert the syntax from VS6 to VS.NET languages in a much more direct

Just converting syntax is a waste of time. Doubly. The time you spent
writing the code in the first place (or whoever else did), AND the time you
spend doing the conversion. If you've got code that works, the only point of
re-writing it in .NET is if you were going to rewrite it anyway even if you
didn't have .NET. Interoperating between unmanaged and managed, and knowing
when to use managed code and when to use unmanaged, is far more fun and
productive.

 

[Guest]

Jon What are the flaws?

C# is much simpler than C++ - and particularly much simpler the VC++
with all its extra macros etc.

Personally I think C# is a lovely language - it has some flaws, but in
general it's great.

Rather than try to convert syntax-for-syntax, I'd strongly advise
learning C# (or VB.NET) from scratch. That way you're more likely to
code in idiomatic C#, rather than C# which looks like it really wants
to be C++.

 

[Jon Skeet [C# MVP]]

Jon What are the flaws?

Just off the top of my head - and some of these are more important than
others, and some would require .NET changes:

1) Lack of an access modifier meaning "accessible within the
namespace".

2) The lock keyword is unnecessary (or would be with a bit more
framework support) - the using statement could handle it. See
http://www.pobox.com/~skeet/csharp/threads/alternative.shtml for what I
think would be a better strategy.

3) Most of the things in v2 should have been in v1

4) I've always thought it would be nice to be able to declare a
variable which is local to a property. It would act as a normal private
as far as the runtime is concerned, but would only be accessible to the
language within the property accessors.

5) Contracts aren't available yet - Spec# is an interesting project,
and I hope it becomes mainstream eventually.

6) Beforefieldinit behaviour is pretty obscure - see
http://www.pobox.com/~skeet/csharp/beforefieldinit.html

7) Sometimes it would be nice to be able to declare variables of
different types within the same using block.

8) When doing UI programming and using multiple threads, it would often
be useful to be able to use a property accessor as a delegate.

9) I prefer the Java way of declaring the namespace/package of a class
- it doesn't eat up horizontal whitespace for no good reason.
Admittedly it adds the restriction that you then can't have two classes
in different namespaces in the same source file, but I don't think
that's really a problem.

 

[Daniel O'Connell [C# MVP]]

Just off the top of my head - and some of these are more important than
others, and some would require .NET changes:

1) Lack of an access modifier meaning "accessible within the
namespace".

Do you really think this is that important? I'm not sure if you mean within
a single namespace and assembly or if you mean any namespace in general, but
I can't see a real use for it other than as syntactic sugar to trick people
into thinking its protection level is effectivly lower than public\internal.

Not that I think its evil, just unsure of its usefulness.

2) The lock keyword is unnecessary (or would be with a bit more
framework support) - the using statement could handle it. See
http://www.pobox.com/~skeet/csharp/threads/alternative.shtml for what I
think would be a better strategy.

Luckily this one can be fixed by popular opinion. The langauge doesn't have
to change and, arguably, the framework should already offer something like
this for langauges like C++ which use RAII type semantics. However, the
pattern can certainly be emulated by

I would also suggest that the casting syntax sucks, .

 

[Jon Skeet [C# MVP]]

Do you really think this is that important?

I've certainly found it irritating.

I'm not sure if you mean within
a single namespace and assembly or if you mean any namespace in general, but
I can't see a real use for it other than as syntactic sugar to trick people
into thinking its protection level is effectivly lower than public\internal.

Not that I think its evil, just unsure of its usefulness.

Often I've ended up with a library where a few classes are interlinked,
but only accessible through a single class which is public or internal.
Without either putting it in a completely separate assembly, or making
them all nested classes you can't make those classes invisible. I just
think it's a bit of a shame.

Luckily this one can be fixed by popular opinion. The langauge doesn't have
to change and, arguably, the framework should already offer something like
this for langauges like C++ which use RAII type semantics. However, the
pattern can certainly be emulated by

Not sure what the end of the sentence was going to be here, but the
problem is that popular opinion is pretty ignorant when it comes to
threading. Harsh but true. Books and articles still regularly recommend
locking on "this" or typeof(TheClass). Maybe over the course of years
popular opinion will come round - I'm not going to hold my breath
though.

I would also suggest that the casting syntax sucks, .

I can see why it does in a theoretical way, and I've seen others
getting confused by it, but it's never been a problem for me
personally. I assume your problem with it is that it does three (or
more?) separate things? (Unboxing, type conversion, and plain casting.)

 

[Daniel O'Connell [C# MVP]]

I'm not sure if you mean within

Often I've ended up with a library where a few classes are interlinked,
but only accessible through a single class which is public or internal.
Without either putting it in a completely separate assembly, or making
them all nested classes you can't make those classes invisible. I just
think it's a bit of a shame.

Ahh, I can see what you mean there. Not sure if per-namespace is nessecerily
the best way, but I do agree that there is a problem there.

Is there a way to do this in java?

Not sure what the end of the sentence was going to be here, but the
problem is that popular opinion is pretty ignorant when it comes to
threading. Harsh but true. Books and articles still regularly recommend
locking on "this" or typeof(TheClass). Maybe over the course of years
popular opinion will come round - I'm not going to hold my breath
though.

That was supposed to be something like:

"However, the pattern can certainly be emulated by any individual who cares
enough."

Not sure how I managed to miss that.

But yes, there is the book issue. I spend quite a bit of time in code
reviews fixing that point, its rather scary how often I see lock(this).

I can see why it does in a theoretical way, and I've seen others
getting confused by it, but it's never been a problem for me

I've had no particular problem with it. Its just like C and java. Still,
didn't care for the design there either.

personally. I assume your problem with it is that it does three (or
more?) separate things? (Unboxing, type conversion, and plain casting.)

Yes, although I can deal with boxing\unboxing being combined with casting.
The MC++ boxing keywords just didn't work that well and would be troublesome
to remember.

However, there are other issues. One is that its syntactically inconsistent,
there is absolutly no other construct in the language that is structured in
the same way. Statements use the same pattern, operators use the same basic
patterns, casting uses two different patterns, one which is just weird in
general(standard casting, (T)obj), and the other one is different from
standard casting(as, obviously).

The other issue is that the construct offers no flexibility. Constructs like
as could have been added in a more consistent way if casting was designed
more like modern C++ casting. There are some future enhancements I'd like to
see, atleast in a specialized dialect, for example guarenteed safe casts
placed for documentation and enforcement purposes. This would be a cast
which is required to be compile-time verified(the type is a base class of
the variable type or implements the variable type interface). These would
exist to both enforce that the assigned object must work at compile time,
and would allow the code to have cleaner self documentation.

Other casts could be used to potentially solve other problems, though I
havn't really thought about any off hand.

 

[Jon Skeet [C# MVP]]

Ahh, I can see what you mean there. Not sure if per-namespace is nessecerily
the best way, but I do agree that there is a problem there.

Is there a way to do this in java?

Sort of. The default access is "package", which is basically namespace
+ derived classes. It's close enough to be helpful, although I'm not
sure why they included derived classes in there.

That was supposed to be something like:

"However, the pattern can certainly be emulated by any individual who cares
enough."

Not sure how I managed to miss that.

But yes, there is the book issue. I spend quite a bit of time in code
reviews fixing that point, its rather scary how often I see lock(this).

At least most C# books don't have the mistake which early Java books
did of claiming that objects are passed by reference...

I've had no particular problem with it. Its just like C and java. Still,
didn't care for the design there either.
Right.


Yes, although I can deal with boxing\unboxing being combined with casting.
The MC++ boxing keywords just didn't work that well and would be troublesome
to remember.

However, there are other issues. One is that its syntactically inconsistent,
there is absolutly no other construct in the language that is structured in
the same way. Statements use the same pattern, operators use the same basic
patterns, casting uses two different patterns, one which is just weird in
general(standard casting, (T)obj), and the other one is different from
standard casting(as, obviously).

I guess that's something which doesn't particularly bother me.

The other issue is that the construct offers no flexibility. Constructs like
as could have been added in a more consistent way if casting was designed
more like modern C++ casting. There are some future enhancements I'd like to
see, atleast in a specialized dialect, for example guarenteed safe casts
placed for documentation and enforcement purposes. This would be a cast
which is required to be compile-time verified(the type is a base class of
the variable type or implements the variable type interface). These would
exist to both enforce that the assigned object must work at compile time,
and would allow the code to have cleaner self documentation.

Other casts could be used to potentially solve other problems, though I
havn't really thought about any off hand.

Yup, that all sounds interesting and good

 

[Daniel O'Connell [C# MVP]]

However, there are other issues. One is that its syntactically

I guess that's something which doesn't particularly bother me.

It didn't bother me either, until I started trying to write a C# compiler. I
had a small amount of trouble getting to to be happy in the grammar and its
been in teh back of my mind ever sense. I was having clashes with cast and
expression grouping grammar, since they both basically look the same(in the
end it was an error of placement with the casting operator, but it still
turned out rather irksome).

Syntactically, a cast is the same as a local-variable-reference-expression
grouped seperatly. Without lookahead its pretty much impossible to tell the
difference between
(Object)
and
(x).

Thankfully C# requires * for multiplication.