|
Yeah, but the different method to acheive what I want is to REIMPLEMENT the IDENTICAL code! I chose the word identical on purpose; I am not doing something similar, it is the same. Both an airplane and a bus have attributes like number of seats, required crew members, lavatories, tire count, etc., but they also have other attributes they share with other things like taillights for the bus, which the plane doesn't have. Reimplementing the SAME thing over and over again is such a waste of my time!
Don't get me wrong, there are some things about C# that are good, like the generic template types, template parameter constraints, built-in collections, more intuitive coding (lets face it, most people don't understand pointers), strong typing of enums, and cleaner more readable code. But I simply don't understand why some of the best parts of other languages were simply not included.
Jeff
|
|
|
|
|
Skippums wrote: Reimplementing the SAME thing over and over again is such a waste of my time!
C# does lend itself to a deep inheritance heirarchy... Then you get into Tweety the Penguin syndrome: Base Class of Birds. Birds Fly. Penguins are birds, but Penguins don't fly. Time for another pair of shim classes - BirdsThatFly{ }, and BirdsThatDontFly{ }.
|
|
|
|
|
Skippums wrote: taillights for the bus, which the plane doesn't have
I thought planes did have tail lights. Isn't that where the term comes from?
|
|
|
|
|
They have an anticollision beacon (the bright red flashing light on top and bottom), running lights (the red and green on the front wingtips, white on the back of the plane), and a landing light or lights. I would consider none of those to be taillights that could be shared with those of a road vehicle, and therefore they should not appear in the airplane class. Regardless, if we ignore semantics and focus on the point, we can see that there are some things that can be categorized in a multitude of ways, and my contention is that an object-oriented language should be able to model that reality, and further, that it should be able to be modeled without any redundancy in code.
Jeff
-- modified at 19:43 Wednesday 28th November, 2007
|
|
|
|
|
If you don't like it, then why program in C#?
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
I do what my boss tells me to do. Besides, it IS good for readability and maintanence.
Jeff
|
|
|
|
|
I guess if the boss says so, you have to.
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
Why not learn C# instead of trying to make it be C++ ? As most types are passed by reference, you essentially have pointers.
You should probably clean up your design before you start coding.
You can't define a class derived from a value type. I wonder if you can derive a class from an int?, I don't know. But, you can define a class which exposes the Id and change the type in there if you want.
I agree that it sucks that we don't have optional parameters. The C# team is caught up in worrying about how to impliment named parameters, although I've told them that just C++ style would be fine.
Skippums wrote: I am also disappointed that an interface member who returns void (nothing) cannot be implemented by a method that returns some other type.
You can't differentiate a method by return type in C++, either.
Christian Graus - Microsoft MVP - C++
"also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
|
|
|
|
|
Christian Graus wrote: Why not learn C# instead of trying to make it be C++ ?
Chrisitian is correct. Gossling tried similar when writing the Java compiler. He tried to adapt a C++ compiler, finding it did not work well. He then wrote the compiler from scratch.
Jeff
|
|
|
|
|
I don't want it to be C++... C++ can be EXTREMELY cryptic. I like MOST of the usability of C#, but the lack of multiple inheritence and typedef'ing is incomprehensible to me (I don't like the unsafe keyword, but I agree with why they included it). I also know that my suggestion on returning something instead of void has yet to be implemented in ANY language that I am aware of, but I don't see why it is not allowed, since it would be easy to implement in the compiler. I just expected that a new language would go the extra mile and give me more flexibility, instead of restricting me so much that I am spending about a tenth of my time jumping through hoops to trick the language into working how I need it to.
As far as your suggestion, "You should probably clean up your design before you start coding", I completely disagree. The type of variable I use for UniqueId should be COMPLETELY decoupled from the class. I shouldn't need to know it's type at all anywhere within the class, and in doing so I strongly couple the implementation of my classes to a particular type. NOT cool!
Oh yeah, and I forgot one more caveat that I find mildly troubling. If I have class A in namespace NA, and class B in namespace NB which inherits from class A, to include class B I am forced to say that I am using namespace NA, despite no reference to NA in my code where I only use class B! This may be to simplify the design of the compiler, and it doesn't reduce my ability to code at all, but it is kind of anoying and unexpected.
Jeff
|
|
|
|
|
Skippums wrote: I just expected that a new language would go the extra mile and give me more flexibility, instead of restricting me so much that I am spending about a tenth of my time jumping through hoops to trick the language into working how I need it to.
What you mean is, you expect a new language to work like the old one. C# is a new language. I went through the same pain, at first I tried to make C# be c++ and it did not work. Now I understand the differences, I know both have limitations, but I am used to working within each of them. I like C#.
Skippums wrote: As far as your suggestion, "You should probably clean up your design before you start coding", I completely disagree.
If you want to decouple something as basic as the nature of an Id, then do it via a class, that makes sense to me.
Skippums wrote: If I have class A in namespace NA, and class B in namespace NB which inherits from class A, to include class B I am forced to say that I am using namespace NA
Yeah, there's no auto namespace lookup. I agree that would be nice, but for every C++ person who expects it, there are 20 who would be troubled to see the namespace imported automatically.
Christian Graus - Microsoft MVP - C++
"also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
|
|
|
|
|
Hi Jeff,
I know the feeling....
I like the abuse available to me using C++, and the slop availble to me using Visual Basic. C# seems to be a bastard child - strongly typed where everything can be a battle - no abuse or slop.
Jeff
|
|
|
|
|
As a former C++ guy myself who still dabbles, I heartily disagree. While it would be nice to have certain C++ features in C#, some aren't there for a good reason. Sometimes you have to step back and look at those reasons, instead of ignoring them and cursing the compiler or language.
By the statements and questions you posed, I also suspect you haven't explored all C# has to offer. Learn the ropes before cursing it, you'll be surprised to find C# to be a beautiful, elegant language.
Now if you're really interested in answers to your questions, I'd be glad to answer them. But I suspect this was more a rant than a Q & A, yes?
Skippums wrote: Oh well, I guess that I will have to start implementing my own compiler so I don't have to put up with the lack of thought and foresight by the "greatest minds" in our field.
Blasphemy!  Just kidding. Seriously though, the folks that designed the C# language are smart, smart folks. Anders Hejlsberg, the lead architect, also designed Turbo Pascal way back in the day, which became a smash success. The man is a seriously smart guy. No offense, but I honestly think everyone in this forum doesn't approach his wits when it comes to language design.
|
|
|
|
|
If you know why they didn't include multiple inheritence and typedef'ing, I would be very interested in hearing (or reading) it.
Jeff
|
|
|
|
|
Maybe they where just copying off java on that one. C# is more of a mix between java and c++ than a direct upgrade from c++.
My current favourite word is: PIE!
I have changed my name to my regular internet alias. But don't let the 'Genius' part fool you, you don't know what 'SK' stands for.
-The Undefeated
|
|
|
|
|
SK Genius wrote: C# is more of a mix between java and c++
I agree. After being a C++ programmer for 15+ years and using java in college, I find C# to be a happy median between the two.
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
typedefs are plain ugly. They are a holdover from C, I thought.
multiple inheritance was not included probably because the design focus of C# is to make it hard to hurt yourself using it. I disagree with them, but that is their focus.
Christian Graus - Microsoft MVP - C++
"also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
|
|
|
|
|
I agree that they CAN be ugly, but all I want is to do something like, "typedef UniqueId as int;", so anywhere I put the word UniqueId, the compiler will know I want it to be an int. I don't understand how strongly coupling my UniqueId property and the integer type within the class is at all helpful. Code maintanance on this is going to be atrocious.
Jeff
|
|
|
|
|
You could in fact create a generic class and define it that way. IMO maintenance on a project where the nature of your unique Id could change in mid stream is no less problematic.
Hell, you can store an object if you want, and then handle it as whatever type you like from there. But if you use generics, then your type won't be boxed if it's a value type.
Christian Graus - Microsoft MVP - C++
"also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
|
|
|
|
|
Hi Jeff,
if you want to be able to write
for(uniqueID id=0; id<10; id++) Console.WriteLine(id.ToString());
then just do it. All it takes is a simple:
using uniqueID=System.Int32;
AFAIK this has been available since day one.
The one thing now really missing from C/C++ is you can't collect statements like the latter
in a single header file and get them included everywhere.
Luc Pattyn [Forum Guidelines] [My Articles]
this months tips:
- before you ask a question here, search CodeProject, then Google
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get
- use PRE tags to preserve formatting when showing multi-line code snippets
|
|
|
|
|
Yeah, it's just that I will still have to have that statement in EVERY file where I reference the type. For maintanence purposes, I will still have to change the using statement in every file. I will probably just end up making my own value type, storing the "real" member as private, then implement the IEquatable and IComparable interfaces, so I can still sort and test for equivalence. Also, this will allow for strong type checking, as apposed to typedef (and I think, the using statement as outlined above) where the types are actually equivalent. Anyway, thanks for the input!
Jeff
|
|
|
|
|
Christian Graus wrote: typedefs are plain ugly. They are a holdover from C, I thought.
Yes, they are ugly. I have always thought that they were carried over from C to maintain portability between older legacy C code and newer C++ code.
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
Well typedefs are prettier than having to say struct X all over the place.
|
|
|
|
|
bingo....your particular desired usage of typedefs typically follows a procedural mentality. ...C++ allows them because C++ is the disgusting bastard child caught in between the (now very)distant past of procedural design and what has been come to be accepted(OOP) as the way things are done from here(actually...probably closer to 10 years ago) until something better can be thought of ...C# is not the problem for placing said restrictions on you...C++ was the problem for allowing you to do them in the first place
"I need build Skynet. Plz send code"
|
|
|
|
|
Why didn't they include multiple inheritence: Big question. Best I can do is point you to an in-depth post by one of the CLR guys who explains in detail why they didn't: http://blogs.msdn.com/csharpfaq/archive/2004/03/07/85562.aspx[^]
Why didn't they include typedef's: well, technically they did, they just limited the scope of typedefs to the file level, which is a good thing IMO.
For example, you can write:
using IntList = System.Collections.Generic.List<int>;
...
public void Foo()
{
IntList list = new IntList();
list.Add(5);
...
}
If you don't like the fact that it's limited to the file level, then I'd just write a value type (e.g. a struct) that holds whatever data you need.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
