Am I the only one that thinks type inference is a bad thing?
-
I was reading on the features of C# 3.0 and lo and behold it seems as if they have found a way to make C# more accessible to vb programmers. I see the future:
var c = "String";
var a = 12345;c = a; //Will eventually be legal, if not already.
On a side not lamda expressions, extension method (only because of the keyword sealed) and the Object initialization are nice.
File Not Found
In vb.net you have the options to turn on Option strict and Option explicit making the example above illegal.
-
I was reading on the features of C# 3.0 and lo and behold it seems as if they have found a way to make C# more accessible to vb programmers. I see the future:
var c = "String";
var a = 12345;c = a; //Will eventually be legal, if not already.
On a side not lamda expressions, extension method (only because of the keyword sealed) and the Object initialization are nice.
File Not Found
Explicit casting should always be there.
Vasudevan Deepak Kumar Personal Homepage Tech Gossips
-
I was reading on the features of C# 3.0 and lo and behold it seems as if they have found a way to make C# more accessible to vb programmers. I see the future:
var c = "String";
var a = 12345;c = a; //Will eventually be legal, if not already.
On a side not lamda expressions, extension method (only because of the keyword sealed) and the Object initialization are nice.
File Not Found
Ennis Ray Lynch, Jr. wrote:
c = a; //Will eventually be legal, if not already.
It's already legal in VB (well, sorta). But that's not what type inference is about. Think of it in terms of getting rid of some of the unfortunate side-effects that came from trying to combine C++ syntax with an object reference-centered runtime. Remember, K&R C wasn't anywhere near as strict about type-checking as modern C++ (or C#) is. This is about letting competent programmers get their work done with less redundant typing...
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
-
I was reading on the features of C# 3.0 and lo and behold it seems as if they have found a way to make C# more accessible to vb programmers. I see the future:
var c = "String";
var a = 12345;c = a; //Will eventually be legal, if not already.
On a side not lamda expressions, extension method (only because of the keyword sealed) and the Object initialization are nice.
File Not Found
Ennis Ray Lynch, Jr. wrote:
var c = "String"; var a = 12345; c = a; //Will eventually be legal, if not already.
I never tried C# 3.0, but the following is legal in C# (1.0, 1.1):
object c = "String";
object a = 12345;
c = a;What is the big difference? Just wondering.
-
Ennis Ray Lynch, Jr. wrote:
var c = "String"; var a = 12345; c = a; //Will eventually be legal, if not already.
I never tried C# 3.0, but the following is legal in C# (1.0, 1.1):
object c = "String";
object a = 12345;
c = a;What is the big difference? Just wondering.
With var, c will still be a string and a will still be an integer, it just saves having to type so much when dealing with really long templated types. It also allows for using variables in templated methods that can't be directly infered from the templated type.
I can imagine the sinking feeling one would have after ordering my book, only to find a laughably ridiculous theory with demented logic once the book arrives - Mark McCutcheon
-
Ennis Ray Lynch, Jr. wrote:
c = a; //Will eventually be legal, if not already.
It's already legal in VB (well, sorta). But that's not what type inference is about. Think of it in terms of getting rid of some of the unfortunate side-effects that came from trying to combine C++ syntax with an object reference-centered runtime. Remember, K&R C wasn't anywhere near as strict about type-checking as modern C++ (or C#) is. This is about letting competent programmers get their work done with less redundant typing...
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
I think that is they key there. Of course there are quite a number of people able to open visual studio and type that I would not consider in the category of competent programmers. Language candy, while nice, makes maintenance a nightmare.
Shog9 wrote:
This is about letting competent programmers get their work done with less redundant typing...
File Not Found
-
I was reading on the features of C# 3.0 and lo and behold it seems as if they have found a way to make C# more accessible to vb programmers. I see the future:
var c = "String";
var a = 12345;c = a; //Will eventually be legal, if not already.
On a side not lamda expressions, extension method (only because of the keyword sealed) and the Object initialization are nice.
File Not Found
Type inference != "type free" c and a are still strongly typed - only the type is inferred from initialization. So
c=ais not legal. And that's a good thing yes sire, especially since introduction of generics.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!|FoldWithUs! | sighist -
Ennis Ray Lynch, Jr. wrote:
var c = "String"; var a = 12345; c = a; //Will eventually be legal, if not already.
I never tried C# 3.0, but the following is legal in C# (1.0, 1.1):
object c = "String";
object a = 12345;
c = a;What is the big difference? Just wondering.
In your example,
cis a reference to astringobject, whileaa reference to a (boxed) integer. Sincecis declared as a reference to anobject(and all types derive from object), you don't have a problem. But try castingcto astringand you'll see...Luis Alonso Ramos Intelectix Chihuahua, Mexico
Not much here: My CP Blog!
-
I was reading on the features of C# 3.0 and lo and behold it seems as if they have found a way to make C# more accessible to vb programmers. I see the future:
var c = "String";
var a = 12345;c = a; //Will eventually be legal, if not already.
On a side not lamda expressions, extension method (only because of the keyword sealed) and the Object initialization are nice.
File Not Found
Replace
varwithobjectand you can pretty much do that already. Excellent for those who think strongly typed languages are for bed-wetting types. Terrible for those who need to debug their programs. I appreciate the concept of a non-typed language but unfortunately we're still using bits to represent our data. Because of this I want to be sure that my fixed point and floating point values remain fixed point and floating point values. I also want to know when a numerical value gets converted to a string because sometimes I really, really don't need the overhead of that conversion. I spend(spent) way too much time with VBScript and Javascript to appreciate weakly-typed languages and their subtle bugs. Much easier having specific types than littering your code with cast operators to force your data into a given type. It makes me sad that applications are now aimed at the lowest common denominator, and sadder still that our development tools are following suit.cheers, Chris Maunder
CodeProject.com : C++ MVP
-
No, C# isn't suddenly going to become JavaScript. The point of
varis to replace this:Dictionary<String, MyBigObjectClassName> dict = new Dictionary<String, MyBigObjectClassName>();
with this:
var dict = new Dictionary<String, MyBigObjectClassName>();
Or in C++, replace:
std::vector<std::pair<std::string, int>>::const_iterator it = someVector.begin();
with:
auto it = someVector.begin();
--Mike-- Visual C++ MVP :cool: LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ Ford, what's this fish doing in my ear?
Ah. An excellent shortcut for development. And one which is going to be seriously abused...
cheers, Chris Maunder
CodeProject.com : C++ MVP
-
Replace
varwithobjectand you can pretty much do that already. Excellent for those who think strongly typed languages are for bed-wetting types. Terrible for those who need to debug their programs. I appreciate the concept of a non-typed language but unfortunately we're still using bits to represent our data. Because of this I want to be sure that my fixed point and floating point values remain fixed point and floating point values. I also want to know when a numerical value gets converted to a string because sometimes I really, really don't need the overhead of that conversion. I spend(spent) way too much time with VBScript and Javascript to appreciate weakly-typed languages and their subtle bugs. Much easier having specific types than littering your code with cast operators to force your data into a given type. It makes me sad that applications are now aimed at the lowest common denominator, and sadder still that our development tools are following suit.cheers, Chris Maunder
CodeProject.com : C++ MVP
Chris Maunder wrote:
littering your code with cast operators
Don't you mean "Runtime Conversion Errors"? And yeah, you're right. Programming languages should be harder to use. The easier it gets, the worse the worldwide codebase becomes. I've written about this before, this degradation in the worldwide collection of code. Eventually, we're going to have massive failures, and then people with experience might finally get paid what we deserve, but we'll hate it. The problem is that schools (and literature) are not teaching concepts, they are teaching languages. When you do that, it's like trying to describe a duck to someone who's never seen a bird before. Students need at least a full semester of concept stuff before they even touch a programming language. I don't understand why experienced college professors, who have probably worked in the industry, don't understand that. My intern is going through this... learning C#, but he doesn't know the basic concepts, so he has to ask me a lot of really basic questions. I'm tempted to go down there and ask the guy what the hell he's teaching, but I'm not this kid's mom :) It is a big waste of time to teach a language unless you use it only as a context for learning the basic concepts. No language that I used in the 1980s is still around today. If I didn't know the concepts, I wouldn't have been able to learn new languages without help. Because I know those concepts, I can look at code in a language I've never seen before, and usually figure it out (with things like LISP and SQL being notable exceptions to that rule)... I don't know if we could teach that ability in schools, but that doesn't mean we shouldn't try.
"Quality Software since 1983!"
http://www.smoothjazzy.com/ - see the "Programming" section for freeware tools and articles.