C# code

[Alvin Bruney]

C# is great but it does have some short comings. Here, I examine one of them
which I definitely think is a shortcoming.
Coming from C++, there seems to be no equivalent in C# to separate code
cleanly for the user's benefit. Why is this important? Because a user gets
to maintain this code, not a machine. C++ exposed us to header files which
was a way, among other things, to cleanly separate class implementation from
declaration. Why was this overlooked in C#? Mixing implementation and
declaration inside a class is so ugly. Yuck!

Sure intellisense can take you a long way, but it's a bandaid on a bruise.
Though it is possible to separate classes out into namespaces in C# you
still have to port the implementation with it. Yuck! A class can be
conceived without an implementation, if only for discussion purposes. You
are not always interested in the implementation, that is why it is so yucky.
What if you want to take the class function declarations with you to a
meeting to talk about your new class? This does actually happen quite
frequently. You can't do that in C# without intimately knowing the cut and
paste editor. Intellisense can't help you there. A class has meaning outside
of the canvas it was carved on. A class does exist outside of the visual
studio GUI. Do not forget, there is no intellisense at the command line.
Probably higher level UML tools in C# builder will fit the bill, but that's
not the point. It should be part of the language implementation because
developers get to maintain that code. It's even more troublesome if these
UML solutions are not included in the box.

We've all gotten used to this mess, and if you come from Java, you've always
had it so it seems odd to be without it. But it doesn't make it right. There
is (make that was) a better way. I remember that time when when
implementation and declaration were different beasts. Sure the compiler
could care less if the implementation was on the moon and declaration on
mars, but then again, a machine does not usually get to maintain code right?
So it was never about the machine. It's about making life easy for
developers. C# has failed in this regard. A more difficult life maintaining
code means less productivity. Yes, it does make me less productive if I need
to figure out the moving parts of a class.

I feel better now after venting.

 

[Daniel O'Connell]

Interesting, one of my favorite features of C#(and java, I suppose) was the
death of the header file.

I recently had to go write a MC++ class and got a reminder on how annoying
it was to have to double define methods, to have parameter lists and return
types defined in TWO places, or my favorite in C, where if you forgot to
define a method the compiler couldn't find it... Hell, when I'm writing C++
code under 500 lines I'll often write my classes like I would in C#.

I personally do not want to go back to these days, I would risk saying that
it wasn't overlooked but turned down inherently.

I guess I jsut don't like header files...I wonder what others think.

 

[Richard A. Lowe]

Not having been a C++ programmer, I wonder if they promote a kind of
Stockholm Syndrome in their long-term users - you have to work with them so
much and so long that you start to feel for them and sympathize with them
until you finally can't live without them.

I have a difficult time imagining headers are better for separating
definition from implementation than an abstract class or interface. Both
are perfectly usable in the real world and both affect the total separation
of implementation from structure.

Richard

--
Veuillez m'excuser, mon Français est très pauvre. Cependant, si vous voyez
mauvais C #, c'est mon défaut!

Interesting, one of my favorite features of C#(and java, I suppose) was the
death of the header file.

I recently had to go write a MC++ class and got a reminder on how annoying
it was to have to double define methods, to have parameter lists and return
types defined in TWO places, or my favorite in C, where if you forgot to
define a method the compiler couldn't find it... Hell, when I'm writing C++
code under 500 lines I'll often write my classes like I would in C#.

I personally do not want to go back to these days, I would risk saying that
it wasn't overlooked but turned down inherently.

I guess I jsut don't like header files...I wonder what others think.

 

[Jon Skeet [C# MVP]]

C# is great but it does have some short comings. Here, I examine one of them
which I definitely think is a shortcoming.
Coming from C++, there seems to be no equivalent in C# to separate code
cleanly for the user's benefit.

The *user* (if you're talking about libraries; if you're not then the
user doesn't see any code at all) should be reading the documentation,
not the code.

Why is this important? Because a user gets
to maintain this code, not a machine.

*That's* why it's important to get rid of the redundancy of
declarations - because humans make mistakes. What's the point of
specifying the same thing twice?

C++ exposed us to header files which
was a way, among other things, to cleanly separate class implementation from
declaration. Why was this overlooked in C#? Mixing implementation and
declaration inside a class is so ugly. Yuck!

I find the C++ way very ugly, myself.

Note that if you want further separation, you can always use a separate
interface in the first place.

Sure intellisense can take you a long way, but it's a bandaid on a bruise.
Though it is possible to separate classes out into namespaces in C# you
still have to port the implementation with it. Yuck! A class can be
conceived without an implementation, if only for discussion purposes.

So use interfaces.

You are not always interested in the implementation, that is why it is so yucky.
What if you want to take the class function declarations with you to a
meeting to talk about your new class?

Print out parts of the documentation. That's much more pleasant than
taking raw code along in the first place.

This does actually happen quite frequently.

I can't remember ever having to actually take such a thing to a meeting
myself, but if I needed to take actual paper (rather than just my
laptop) to a meeting with the interface on it, I'd print out the
documentation for the class.

You can't do that in C# without intimately knowing the cut and
paste editor. Intellisense can't help you there. A class has meaning outside
of the canvas it was carved on. A class does exist outside of the visual
studio GUI. Do not forget, there is no intellisense at the command line.
Probably higher level UML tools in C# builder will fit the bill, but that's
not the point. It should be part of the language implementation because
developers get to maintain that code. It's even more troublesome if these
UML solutions are not included in the box.

We've all gotten used to this mess, and if you come from Java, you've always
had it so it seems odd to be without it.

Alternatively, you've gotten used to the mess in C++, which is why you
feel lost without it. Have you considered that possibility?

But it doesn't make it right.

See above

There is (make that was) a better way. I remember that time when when
implementation and declaration were different beasts.

Yes, and I was forever checking out two files and making similar
changes to both whenever I wanted to add a new method. Yuk!

Sure the compiler
could care less if the implementation was on the moon and declaration on
mars, but then again, a machine does not usually get to maintain code right?
So it was never about the machine. It's about making life easy for
developers.

Specifying the same thing twice is easier than only specifying it once?

C# has failed in this regard. A more difficult life maintaining
code means less productivity. Yes, it does make me less productive if I need
to figure out the moving parts of a class.

I think you seriously need to look at NDoc... I'd much rather look at
documentation for a class than raw C++ headers.

 

[Alan Pretre]

C++ exposed us to header files which
was a way, among other things, to cleanly separate class implementation from
declaration.

This isn't quite true. There is much in a C++ class declaration that
reveals its implementation. For example, all of its private members and
methods, and its ancestors. .NET Interfaces are much better than this
because they only show the public members.

-- Alan

 

[Alvin Bruney]

I recently had to go write a MC++ class and got a reminder on how annoying

it was to have to double define methods,

No runtime allows double definition of methods, I'm sure I must have missed
your point. Would you care to clarify?. Overloaded methods are entirely
different.

--


-----------
Got TidBits?
Get it here: www.networkip.net/tidbits

Interesting, one of my favorite features of C#(and java, I suppose) was the
death of the header file.

I recently had to go write a MC++ class and got a reminder on how annoying
it was to have to double define methods, to have parameter lists and return
types defined in TWO places, or my favorite in C, where if you forgot to
define a method the compiler couldn't find it... Hell, when I'm writing C++
code under 500 lines I'll often write my classes like I would in C#.

I personally do not want to go back to these days, I would risk saying that
it wasn't overlooked but turned down inherently.

I guess I jsut don't like header files...I wonder what others think.

 

[Alvin Bruney]

I have a difficult time imagining headers are better for separating
but that's the whole point you are missing. Why do I need to implement an
interface just to get what I want? I do not want an interface because it
forces me into an avenue I'm not prepared to handle (certainly, that's valid
for some reasons). And why should this separation come at a price of using
interfaces and it's baggage. With C++, that separation is clean and free. It
doesn't force you to implement some other feature just to get what you are
asking. Unlike C#

Guess you all are java guys uh? I'd better head for the exit

--


-----------
Got TidBits?
Get it here: www.networkip.net/tidbits

Not having been a C++ programmer, I wonder if they promote a kind of
Stockholm Syndrome in their long-term users - you have to work with them so
much and so long that you start to feel for them and sympathize with them
until you finally can't live without them.

I have a difficult time imagining headers are better for separating
definition from implementation than an abstract class or interface. Both
are perfectly usable in the real world and both affect the total separation
of implementation from structure.

Richard

 

[Alvin Bruney]

The *user* (if you're talking about libraries; if you're not then the

user doesn't see any code at all) should be reading the documentation,
not the code.

c'mon Jon,
you know this aint real world. How many times has docs kept up with the
source code. Its wrong but it's true, programmers prefer to look at source
rather than docs. Occasionally, you may find someone heading to the docs but
by far, most programmers consult the source code first.

Note that if you want further separation, you can always use a separate
interface in the first place.

No you are selling me something I don't want just to get what I want. I want
to separate a class implementation from its declaration. I don't want to be
forced to carry an interface baggage. Is there a way to do that in C#? No.

Yes, and I was forever checking out two files and making similar
changes to both whenever I wanted to add a new method. Yuk!

how is that different from interfaces?

Alternatively, you've gotten used to the mess in C++, which is why you
feel lost without it. Have you considered that possibility?

Some parts of that are true. Lost is a strong word though.

 

[Jon Skeet [C# MVP]]

c'mon Jon,
you know this aint real world. How many times has docs kept up with the
source code. Its wrong but it's true, programmers prefer to look at source
rather than docs.

So when they want to see the implementation, they look at the real
source. They'd have to do that in C++ as well, so you haven't shown any
benefit there.

Occasionally, you may find someone heading to the docs but
by far, most programmers consult the source code first.

I don't believe that's the case with .NET and languages like Java where
there's a common documentation system which they'll be used to for the
base libraries to start with. When JavaDoc is provided with a Java
library, that's what people look at first, IME - followed by whatever
other documentation is provided, followed by the code itself.

No you are selling me something I don't want just to get what I want. I want
to separate a class implementation from its declaration.

Why though? None of your arguments so far hold water, as far as I've
seen.

I don't want to be
forced to carry an interface baggage. Is there a way to do that in C#? No.

Thank goodness, IMO.

how is that different from interfaces?

I (usually) don't *have* to use interfaces when I don't want to, and I
don't have to add declarations for private members.

 

[Alvin Bruney]

Why though? None of your arguments so far hold water, as far as I've

seen.

gowd,
i'm heading for the exits. java programmers out to get me...

 

[Fred Mellender]

If you right click in the source window for a class (in the MDE), select
outline/collapse-to-definitions, you get what looks like a ".h" file. All
the code is hidden; the definitions remain. Isn't this the same convenience
as having a .h file to look at? If you print the file while the code is
collapsed, you get a print-out you can use as if it were a .h file.

I recently had to go write a MC++ class and got a reminder on how annoying
it was to have to double define methods,

No runtime allows double definition of methods, I'm sure I must have missed
your point. Would you care to clarify?. Overloaded methods are entirely
different.

 

[Alvin Bruney]

hmmm,
i didnt know it printed collapse.

If this really works (no printer installed in new office) then I guess my
arguments don't hold water. Blame it on ignorance. This round goes to .NET!
regards

--


-----------
Got TidBits?
Get it here: www.networkip.net/tidbits

If you right click in the source window for a class (in the MDE), select
outline/collapse-to-definitions, you get what looks like a ".h" file. All
the code is hidden; the definitions remain. Isn't this the same convenience
as having a .h file to look at? If you print the file while the code is
collapsed, you get a print-out you can use as if it were a .h file.

No runtime allows double definition of methods, I'm sure I must have missed
your point. Would you care to clarify?. Overloaded methods are entirely
different.

--


-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
was
the writing
C++ user
gets purposes.
You cut
and

declaration

on

if

 

[Ray Hsieh (Ray Djajadinata)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I come from a C/C++ background as well, before going to Java and then
C#. I think Java's and C#'s approaches are just fine.

Don't get me wrong, I know your pain, I've been through that the first
time I moved to Java. I was so used to checking the header file when I
wanted a quick peek at the *declarations*, especially because the Class
View of VS back then was sometimes not very helpful, thanks to the macro
expansion, message maps, and all those yucky stuff that comes with MFC
and ATL.

So my first reflex when I wanted to check the declarations quickly, in
Java, was to open the Java source files, which seemed excessively
cluttered, exactly for the reason you mentioned. But then I realized
something: I had to open C++ header files because the tool didn't give
me good enough support back then. In Java, however, any decent IDE will
give you all the info you need the moment you add a JAR file into your
project.

So this is about declarations, and we've addressed that

What about implementation? In all 3 languages, if you want to look at
the implementation, you *have* to endure all those clutter *anyway*. And
note that in all 3 languages, the vendor can always choose to hide their
implementation, be it in a .lib, .dll, or .jar. So no, C++ approach is
not better. It is more primitive, even.

And I think maintaining ONE file for each class is better than
maintaining TWO files for each class, thank you. Especially (now I'm
talking about Java here) with the extensive refactoring support
available in many popular Java IDEs.

And don't even get me started about the mess of declaring static
variable and the linker errors in C++! Argh!

Alvin Bruney wrote:

| gowd,
| i'm heading for the exits. java programmers out to get me...

- --
Ray Hsieh (Ray Djajadinata) [SCJP, SCWCD]
ray underscore usenet at yahoo dot com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQE/oVJlwEwccQ4rWPgRAq7jAJ9W4MlrzSj+QvLPfkMxW7jwfLqwSACfTynY
HMiXdvBwTJ9Q0/kEFFGQ+nQ=
=FMQk
-----END PGP SIGNATURE-----

 

[Daniel O'Connell]

Actually, I cut my teeth on x86 Assembly and C\C++, then VB and C#, never
really learned Java. I just think C\C++ has an inherently troubled model for
alot of things, including type definitions.

I have a difficult time imagining headers are better for separating

but that's the whole point you are missing. Why do I need to implement an
interface just to get what I want? I do not want an interface because it
forces me into an avenue I'm not prepared to handle (certainly, that's valid
for some reasons). And why should this separation come at a price of using
interfaces and it's baggage. With C++, that separation is clean and free. It
doesn't force you to implement some other feature just to get what you are
asking. Unlike C#

Guess you all are java guys uh? I'd better head for the exit

--


-----------
Got TidBits?
Get it here: www.networkip.net/tidbits

Not having been a C++ programmer, I wonder if they promote a kind of
Stockholm Syndrome in their long-term users - you have to work with them so
much and so long that you start to feel for them and sympathize with them
until you finally can't live without them.

I have a difficult time imagining headers are better for separating
definition from implementation than an abstract class or interface. Both
are perfectly usable in the real world and both affect the total separation
of implementation from structure.

Richard

--
Veuillez m'excuser, mon Fran$BmB(Bis est tr$BoT(B pauvre. Cependant, si vous voyez
mauvais C #, c'est mon d$BqG(Baut!
was
the writing
C++ user
gets purposes.
You cut
and

declaration

on

if

 

[Daniel O'Connell]

No runtime allows double definition of methods, I'm sure I must have missed
your point. Would you care to clarify?. Overloaded methods are entirely
different.

I mean, for example
//in a header file
void MyFunction(String *x);

//in my CPP file
void MyFunction(String *x)
{

}

then, I want to change MyFunction to MyFunction(String *x, int y); I have to
change the code in 2 places, which I find to be a bad design, two
definitions of the method that must match.

 

[Alvin Bruney]

right. thanks for clarifying.

I agree with your analysis. you never get to see how ugly C++ is if you are
right up in there working it.

I always barked at people who claimed C++ was ugly. Then I spent a year in
C# came back to C++ (to help a student write some code actually) and I was
like 'what the f#$%@ is this S@#$%% That's when it hit me how bad the model
was. That's when I could see what the java programmers were fussing about.
That's when I realized pointers and pointer syntax was difficult if not
problematic.

But there are still some good things about the language though. I like STL,
templates, generics, the idea behind ATL and gowd bless the MFC. Still, say
what you want, C++ is intimidating. I now see that it doesn't need to be. It
is pointlessly intimidating. Its such a pitty that folk like Stroustrup and
Gosling cannot see the error in their ways and embrace this new language,
maybe even copy from it to extend C++ and breathe new life into it a dying
platform, cuz it's going down.

regards

--


-----------
Got TidBits?
Get it here: www.networkip.net/tidbits

No runtime allows double definition of methods, I'm sure I must have missed
your point. Would you care to clarify?. Overloaded methods are entirely
different.

I mean, for example
//in a header file
void MyFunction(String *x);

//in my CPP file
void MyFunction(String *x)
{

}

then, I want to change MyFunction to MyFunction(String *x, int y); I have to
change the code in 2 places, which I find to be a bad design, two
definitions of the method that must match.

--


-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
was
the writing
C++ user
gets purposes.
You cut
and

declaration

on

if

 

[Daniel O'Connell]

right. thanks for clarifying.

I agree with your analysis. you never get to see how ugly C++ is if you are
right up in there working it.

I always barked at people who claimed C++ was ugly. Then I spent a year in
C# came back to C++ (to help a student write some code actually) and I was
like 'what the f#$%@ is this S@#$%% That's when it hit me how bad the model
was. That's when I could see what the java programmers were fussing about.
That's when I realized pointers and pointer syntax was difficult if not
problematic.

But there are still some good things about the language though. I like STL,
templates, generics, the idea behind ATL and gowd bless the MFC. Still, say
what you want, C++ is intimidating. I now see that it doesn't need to be.

It

It is troublingly intimidating sometimes, in some ways because of
compatibiltiy. I like some features but I consider some of them to be badly
designed. Templates and macros for example are often a source of absolute
HELL, one little mistake somewhere in a maze of define muck and you get
errors that don't make sense. One problem I was having was trying to use a
macro that required another macro to be included that I had forgotten
about...its messy and unpleasent. There is alot of power there but they can
also totally destroy any chance you have of figuring out what really went
wrong in some circumstances. I am willing to give up a little of that power
for C# style generics and no macros.

is pointlessly intimidating. Its such a pitty that folk like Stroustrup and
Gosling cannot see the error in their ways and embrace this new language,
maybe even copy from it to extend C++ and breathe new life into it a dying
platform, cuz it's going down.

regards

--


-----------
Got TidBits?
Get it here: www.networkip.net/tidbits

message news:%[email protected]...
I mean, for example
//in a header file
void MyFunction(String *x);

//in my CPP file
void MyFunction(String *x)
{

}

then, I want to change MyFunction to MyFunction(String *x, int y); I

have

to
change the code in 2 places, which I find to be a bad design, two
definitions of the method that must match.

forgot

to wrote
in one
of C#
you

to

 

[Richard A. Lowe]

Alvin, no-one's out to get you. I don't feel I or anyone else has
'attacked' you - but if you feel that way, then, I am sorry if I've failed
to convey that with the attempt at a joke in my post... it wasn't aimed at
you.

All I am interested in is what the discussion is about. I can't see the use
cases for header files, just answer my and Jon and Ray's arguments and maybe
you'll convince one or more of us. I don't think it's a 'religious' issue
like C# vs. Java - just that I, for one, am not understanding why you think
headers would be better than the responses we gave you..

Richard

--
Veuillez m'excuser, mon Français est très pauvre. Cependant, si vous voyez
mauvais C #, c'est mon défaut!

Why though? None of your arguments so far hold water, as far as I've
seen.

gowd,
i'm heading for the exits. java programmers out to get me...

--


-----------
Got TidBits?
Get it here: www.networkip.net/tidbits

So when they want to see the implementation, they look at the real
source. They'd have to do that in C++ as well, so you haven't shown any
benefit there.


I don't believe that's the case with .NET and languages like Java where
there's a common documentation system which they'll be used to for the
base libraries to start with. When JavaDoc is provided with a Java
library, that's what people look at first, IME - followed by whatever
other documentation is provided, followed by the code itself.

I

 

[Jon Skeet [C# MVP]]

All I am interested in is what the discussion is about. I can't see the use
cases for header files, just answer my and Jon and Ray's arguments and maybe
you'll convince one or more of us. I don't think it's a 'religious' issue
like C# vs. Java - just that I, for one, am not understanding why you think
headers would be better than the responses we gave you..

Note that C# vs Java doesn't have to be a religious issue either. I've
never really understood the people who'd rather hide behind the FUD
(both ways) where each "side" claims that the other's platform/language
is slow, inelegant, proprietary etc.

I use both and like both, and really can't see why it's such a big deal
or why people are *so* keen to put down the language/platform that they
don't happen to use...

 

[Alvin Bruney]

Alvin, no-one's out to get you. I don't feel I or anyone else has

hey, my humor is about as dry and sarcastic as they come. I take no offense
to posts here. non at all. stick around, you'll figure it out. it's all
good.
--


-----------
Got TidBits?
Get it here: www.networkip.net/tidbits

Alvin, no-one's out to get you. I don't feel I or anyone else has
'attacked' you - but if you feel that way, then, I am sorry if I've failed
to convey that with the attempt at a joke in my post... it wasn't aimed at
you.

All I am interested in is what the discussion is about. I can't see the use
cases for header files, just answer my and Jon and Ray's arguments and maybe
you'll convince one or more of us. I don't think it's a 'religious' issue
like C# vs. Java - just that I, for one, am not understanding why you think
headers would be better than the responses we gave you..

Richard

--
Veuillez m'excuser, mon Français est très pauvre. Cependant, si vous voyez
mauvais C #, c'est mon défaut!

gowd,
i'm heading for the exits. java programmers out to get me...

want.