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.
--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits 25  2081 
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" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:%2******************@TK2MSFTNGP11.phx.gbl... 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.
--
-----------
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çais est très pauvre. Cependant, si vous voyez
mauvais C #, c'est mon défaut!
"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:lq0ob.59629$Fm2.42234@attbi_s04... 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" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:%2******************@TK2MSFTNGP11.phx.gbl... 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.
--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
Alvin Bruney <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote: 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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:%2******************@TK2MSFTNGP11.phx.gbl... 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
> 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
"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:lq0ob.59629$Fm2.42234@attbi_s04... 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" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:%2******************@TK2MSFTNGP11.phx.gbl... 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.
--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
> 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
"Richard A. Lowe" <ch*****@yumspamyumYahoo.com> wrote in message
news:#p**************@TK2MSFTNGP09.phx.gbl... 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!
"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:lq0ob.59629$Fm2.42234@attbi_s04... 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" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote
in message news:%2******************@TK2MSFTNGP11.phx.gbl... 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.
--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
>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.
--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Alvin Bruney <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote: 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.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Alvin Bruney <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote: 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.
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.
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.
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.
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?
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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
> 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
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Alvin Bruney <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote: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.
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.
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.
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.
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?
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.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
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.
"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:%2****************@TK2MSFTNGP11.phx.gbl... 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
"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:lq0ob.59629$Fm2.42234@attbi_s04... 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" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote
in message news:%2******************@TK2MSFTNGP11.phx.gbl... 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.
--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
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
"Fred Mellender" <no****************@frontiernet.net> wrote in message
news:MC*****************@news02.roc.ny... 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.
"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:%2****************@TK2MSFTNGP11.phx.gbl... 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
"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:lq0ob.59629$Fm2.42234@attbi_s04... 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" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in message news:%2******************@TK2MSFTNGP11.phx.gbl...
> 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.
>
> --
>
>
> -----------
> Got TidBits?
> Get it here: www.networkip.net/tidbits
>
>
-----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+QvLPfkMxW7jwfLqwSA CfTynY
HMiXdvBwTJ9Q0/kEFFGQ+nQ=
=FMQk
-----END PGP SIGNATURE-----
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.
"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:u%******************@TK2MSFTNGP11.phx.gbl... 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
"Richard A. Lowe" <ch*****@yumspamyumYahoo.com> wrote in message
news:#p**************@TK2MSFTNGP09.phx.gbl... 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!
"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:lq0ob.59629$Fm2.42234@attbi_s04... 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" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in message news:%2******************@TK2MSFTNGP11.phx.gbl...
> 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.
>
> --
>
>
> -----------
> Got TidBits?
> Get it here: www.networkip.net/tidbits
>
>
"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:%2****************@TK2MSFTNGP11.phx.gbl... 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.
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
"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:lq0ob.59629$Fm2.42234@attbi_s04... 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" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote
in message news:%2******************@TK2MSFTNGP11.phx.gbl... 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.
--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
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
"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:7piob.65341$Tr4.174983@attbi_s03...
"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:%2****************@TK2MSFTNGP11.phx.gbl... 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.
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
"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:lq0ob.59629$Fm2.42234@attbi_s04... 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" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in message news:%2******************@TK2MSFTNGP11.phx.gbl...
> 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.
>
> --
>
>
> -----------
> Got TidBits?
> Get it here: www.networkip.net/tidbits
>
>
"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:e3****************@TK2MSFTNGP12.phx.gbl... 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
"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:7piob.65341$Tr4.174983@attbi_s03...
"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote
in message news:%2****************@TK2MSFTNGP11.phx.gbl... > 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.
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
"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:lq0ob.59629$Fm2.42234@attbi_s04...
> 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" <vapordan_spam_me_not@hotmail_no_spamhotmail.com >
wrote in > message news:%2******************@TK2MSFTNGP11.phx.gbl...
> > 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.
> >
> > --
> >
> >
> > -----------
> > 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!
"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:uv*************@TK2MSFTNGP10.phx.gbl... 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
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Alvin Bruney <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote: >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.
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.
> 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.
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.
> 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?
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.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Richard A. Lowe <ch*****@yumspamyumYahoo.com> wrote: 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...
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
> 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
"Richard A. Lowe" <ch*****@yumspamyumYahoo.com> wrote in message
news:#Z**************@TK2MSFTNGP12.phx.gbl... 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!
"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:uv*************@TK2MSFTNGP10.phx.gbl... 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
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Alvin Bruney <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote:
> >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.
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.
> > 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.
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.
> > 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?
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.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Then thank your lucky stars if you weren't around when the java trolls used
to start month long flame wars here. :)
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... 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...
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Daniel Billingsley <db**********@NO.durcon.SPAAMM.com> wrote: Then thank your lucky stars if you weren't around when the java trolls used
to start month long flame wars here. :)
To be honest, most of the C#/Java FUD I've seen here has been from
people who claim that Java is interpreted, or is hideously slow etc.
I see some similar stuff on the Java newsgroups, but correct it when I
spot it :)
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jon Skeet [C# MVP] <sk***@pobox.com> wrote in message news:<MP************************@msnews.microsoft. com>... Richard A. Lowe <ch*****@yumspamyumYahoo.com> wrote: 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 wholeheartedly agree! I guess I chose that example because it
appears Messrs. Ballmer and McNealy seem to want it to be that way.
In truth, developers are the ones who will lose if we don't
cross-pollinate our ideas and experiences.
Richard
Well, the trolls used to make statements like "C# sucks because it's just a
clone of java" or "java is better because it's simpler" (yes, someone
actually said that) and you can imagine the nonsense that resulted
considering the stupidity of the opening premise. And to be sure, they
would inevitably include a fair dose of FUD from the MS side as well.
I don't know why it's so hard to accept/admit that both have their
advantages and disadvantages.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Daniel Billingsley <db**********@NO.durcon.SPAAMM.com> wrote: Then thank your lucky stars if you weren't around when the java trolls
used to start month long flame wars here. :)
To be honest, most of the C#/Java FUD I've seen here has been from
people who claim that Java is interpreted, or is hideously slow etc.
I see some similar stuff on the Java newsgroups, but correct it when I
spot it :)
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
what does FUD mean?
--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message
news:Oe**************@TK2MSFTNGP09.phx.gbl... Well, the trolls used to make statements like "C# sucks because it's just
a clone of java" or "java is better because it's simpler" (yes, someone
actually said that) and you can imagine the nonsense that resulted
considering the stupidity of the opening premise. And to be sure, they
would inevitably include a fair dose of FUD from the MS side as well.
I don't know why it's so hard to accept/admit that both have their
advantages and disadvantages.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Daniel Billingsley <db**********@NO.durcon.SPAAMM.com> wrote: Then thank your lucky stars if you weren't around when the java trolls used to start month long flame wars here. :)
To be honest, most of the C#/Java FUD I've seen here has been from
people who claim that Java is interpreted, or is hideously slow etc.
I see some similar stuff on the Java newsgroups, but correct it when I
spot it :)
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message
news:Oe****************@TK2MSFTNGP09.phx.gbl... Well, the trolls used to make statements like "C# sucks because it's just
a clone of java"
Hiw silly. That's one of its main advantages. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Mudge |
last post by:
Please, someone, tell me why OO in PHP is better than procedural.
|
by: bigoxygen |
last post by:
Hi.
I'm using a 3 tier FrontController Design for my web application right
now.
The problem is that I'm finding to have to duplicate a lot of code for
similar functions; for example, listing...
|
by: jason |
last post by:
Hello.
Newbie on SQL and suffering through this.
I have two tables created as such:
drop table table1;
go
drop table table2;
go
|
by: Dario de Judicibus |
last post by:
I'm getting crazy. Look at this code:
#include <string.h>
#include <stdio.h>
#include <iostream.h>
using namespace std ;
char ini_code = {0xFF, 0xFE} ;
char line_sep = {0x20, 0x28} ;
|
by: Andrew Thompson |
last post by:
It seems most people get there JS off web sites, which is
entirely logical. But it is also a great pity since most
of that code is of such poor quality.
I was looking through the JS FAQ for any...
|
by: ED |
last post by:
I currently have vba code that ranks employees based on their average
job time ordered by their region, zone, and job code. I currently
have vba code that will cycle through a query and ranks each...
|
by: Namratha Shah \(Nasha\) |
last post by:
Hey Guys,
Today we are going to look at Code Access Security.
Code access security is a feature of .NET that manages code depending on its
trust level. If the CLS trusts the code enough to...
|
by: Joe Fallon |
last post by:
I have some complex logic which is fairly simply to build up into a string.
I needed a way to Eval this string and return a Boolean result.
This code works fine to achieve that goal.
My...
|
by: Alan Silver |
last post by:
Hello,
Newbie here, so please forgive what is probably a basic question ...
I see a lot of discussion about "code behind", which if I have
understood correctly, means that the script code goes...
|
by: tshad |
last post by:
I am just trying to decide whether to split my code and uses code behind. I
did it with one of my pages and found it was quite a bit of trouble.
I know that most people (and books and articles)...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
