Generics in Whidbey 1

MSDN has an interesting article on using Generics in the upcoming release of VS.NET (codenamed Whidbey).

http://msdn.microsoft.com/msdnmag/issues/03/10/NET/default.aspx

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first

 

[Dinobrago]

Thanks!
d-

 

[Cheiron]

Thanks Chiph,

That is an interesting article. At first the restrictions on generics (compared to C++) seem to make generics almost useless, but then when you see the new

where T : IComparable

style syntax, things exapand back into usefullness.

It seems like a better solution than the looser C++ approach. The model will certainly make errors easier to understand versus the monster error messages seen in STL or ATL.

 

[chiph]

where T : IComparable
style syntax, things expand back into usefullness.

Yes - when they raised the limitation of the type T must be resolvable at compile time into any possible type T, that would really put a crimp in what you could use them for -- Like they said: what if my type doesn't have a &quot;<&quot; operator?

By letting you explicitly tell the compiler &quot;I won't send you anything but the types that implement this interface&quot;, or &quot;types of this type, or types inherited from that type&quot;, then it really opens it back up for the programmer.

I'm a little concerned about some of the other uses shown further down in the article -- programmers coming from a C++ background will be able to make use of them, but people like myself who only use C++ occasionally (or VB6 programmers making the move to C#), it will be pretty incomprehensable. I suspect it's a case of: If you need to do something like that (and it's unlikely that you will in a typical business app), it's there for you.

The error messages certainly improved once they allowed you to restrict the type in your generic implementation. If I saw the first one they had, I'd be spending days trying to figure out what it really meant!

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first

 

[Cheiron]

You raise an interesting point on readability. Languages always seem to start with ease of use and straigtforward readability as the dominant forces, and then move to power over time, but perhaps the languages never really target simplicity at the beginning; simplicity happens at first because of a lack of time to add all the features in v1.0.

There is a great way for Microsoft to address this concern in .Net. Maybe they are taking advantage of it.

There do not seem to be immediate plans to add generics to VB.Net. Looking at the only slight differences between the two languages one would have to conclude that either Microsoft introduced both of them simply to make migration slightly easier for people with different syntax affinities (sort of liking having multiple color M&Ms, just because some people prefer red), in which case the logical course would be to eventually merge them (into something like cb.net) just so people would stop asking what the differences are (given that languages are NOT like a bowl of M&Ms) -- or, conversely, that they introduced both of them in the expectation that the two would diverge somewhat over time (consistent with some of the earliest positioning by Microsoft of the two langauges).

In other words, maybe the answer is that VB programers, who probably would have been willing to learn C++ if it weren't for templates, would use VB.Net, keeping them safe from generics, and C# programmers, many of whom came from C++ and won't be happy until they have something like templates, will embrace them in C#. Microsoft would keep VB.Net simple, and make C# more powerful.

It is impossible to know where Redmond will take things (they could surprise me and announce generics for VB.Net tomorrow) but letting the languages diverge a little more certainly would address the concern you raised, while providing people who are willing to traverse the learning curve access to the facilities they want. This would give the two languages more of a reason to coexist, and would be consistent with that differences that exist in the two languages today.

 

[chiph]

There do not seem to be immediate plans to add generics to VB.Net.

I think the author said that the C# version was closer to being done, and that's why he used it in the article. Which sort of implies that it will be available for the other CLR-compliant languages eventually (COBOL.NET with generics??!!)

in which case the logical course would be to eventually merge them (into something like cb.net) just so people would stop asking what the differences are

So, I'm not the only one who is getting tired of the &quot;Why is C# better than xyz&quot; posts!


I'm a little curious too as to what the grand scheme is for VB.NET. The original language was the champ at doing RAD stuff, and if you were really talented and disciplined, you could write good apps with it. With VB.NET, the RAD is sortof still there. But with all the new advanced features, the typical VB programmer is having a tough time making the transition from procedural code to O-O design (see all the &quot;How do I call a method on Form2 from Form1?&quot; posts in the VB.NET forum).

There's already some alienation going on within the VB community. Maybe Microsoft would be better off *not* putting all the power of .NET into VB.NET? Let it continue to fulfill the RAD role, and let production-quality apps be written in C# and managed C++?

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first

 

[benlinkknilneb]

I'm curious... maybe y'all can explain this one to me.

My prof (who is Sun-certified in Java outside of school) for a Data Structures course said that instead of using templates in Java, they just write generic functions for class object and let the inheritance tree determine the implementation of the method. I know there is a type &quot;object&quot; in C#... what's the difference between that and these generics? What can I do with templated classes that I couldn't do with the &quot;object&quot; technique?

Ben
A programmer was drowning. Lots of people watched but did nothing. They couldn't understand why he yelled &quot;F1!&quot;

 

[chiph]

Ben -

If you use the &quot;Object&quot; way of doing things (which is what the CLR currently does), you have no type safety. There is nothing preventing a programmer adding a &quot;cat&quot; object to a collection that is supposed to only contain &quot;dog&quot; objects. Because the collection accepts/returns objects of type Object, and because cat and dog both ultimately inherit from Object (part of the .NET spec), then there's no error thrown when a programmer does this ... *until* they try and access the .bark method of a cat object, or do an assignment of the cat object to a variable of type dog.

With Generics (aka Templates), you tell the collection what type of objects he will contain when you instantiate it. Thereafter, it behaves as if it only knows about dog objects, and an attempt to add a cat object will be flagged as a compiler error (programmer slaps head and says &quot;Duh!&quot.

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first

 

[benlinkknilneb]

OOOHHHH.... I get it now. Didn't think about it from that angle. So then, given the ability to do either one, it's better practice to use the templates instead of inheriting from Object?

Ben
A programmer was drowning. Lots of people watched but did nothing. They couldn't understand why he yelled &quot;F1!&quot;

 

[chiph]

In C#, for sure.

Some of the other languages have runtime type-checking which can slow things down. But if you're running C#, you aren't interested in pure speed anyway (writing a first-person game like Quake in C# would be pointless, as it won't be fast enough).

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first