.NET 1.x Is Why We Can't Have Nice Things Reason #32
-
Because 1.x existed prior to generics we have issues of legacy object models not implementing
IList<T>and instead simply exposing hard typed indexer properties. Normally, you'd just get the generic parameters of the genericIEnumerable<T>interface, but because some object trees were created prior to 2.0 - like the CodeDOM they don't have them. This makes determining the element type of a typed list extremely difficult. The problem is that your alternative is the indexer property which isn't a member of a hard interface, so you have to select the appropriate indexer property from the properties on that type. There might bethis[string name]in there too, for example. There is no contract however, so there are no guarantees. This isn't especially robust. Which means, the obvious solution is to first try to get it using the generic interfaces, and if they aren't available, then we fall back to the less robust method above. This is not ideal, and it requires maybe a page of code to handle all the scenarios. Microsoft didn't put generics into 1.x I think because of time constraints, and if so they should have waited, IMO. Edit: For anyone interested I just posted a tip that solves this problem. How To Get A Collection Element Type Using Reflection in C#[^]Real programmers use butterflies
-
Because 1.x existed prior to generics we have issues of legacy object models not implementing
IList<T>and instead simply exposing hard typed indexer properties. Normally, you'd just get the generic parameters of the genericIEnumerable<T>interface, but because some object trees were created prior to 2.0 - like the CodeDOM they don't have them. This makes determining the element type of a typed list extremely difficult. The problem is that your alternative is the indexer property which isn't a member of a hard interface, so you have to select the appropriate indexer property from the properties on that type. There might bethis[string name]in there too, for example. There is no contract however, so there are no guarantees. This isn't especially robust. Which means, the obvious solution is to first try to get it using the generic interfaces, and if they aren't available, then we fall back to the less robust method above. This is not ideal, and it requires maybe a page of code to handle all the scenarios. Microsoft didn't put generics into 1.x I think because of time constraints, and if so they should have waited, IMO. Edit: For anyone interested I just posted a tip that solves this problem. How To Get A Collection Element Type Using Reflection in C#[^]Real programmers use butterflies
I agree. V1 should never have seen the light of day. And sub-teams working on different areas should have communicated, and there should have been a core team to determine commonalities. I mean, seriously!? :wtf:
public ArgumentException (string message, string paramName);
public ArgumentOutOfRangeException (string paramName, string message);
public ArgumentNullException (string paramName, string message); -
Because 1.x existed prior to generics we have issues of legacy object models not implementing
IList<T>and instead simply exposing hard typed indexer properties. Normally, you'd just get the generic parameters of the genericIEnumerable<T>interface, but because some object trees were created prior to 2.0 - like the CodeDOM they don't have them. This makes determining the element type of a typed list extremely difficult. The problem is that your alternative is the indexer property which isn't a member of a hard interface, so you have to select the appropriate indexer property from the properties on that type. There might bethis[string name]in there too, for example. There is no contract however, so there are no guarantees. This isn't especially robust. Which means, the obvious solution is to first try to get it using the generic interfaces, and if they aren't available, then we fall back to the less robust method above. This is not ideal, and it requires maybe a page of code to handle all the scenarios. Microsoft didn't put generics into 1.x I think because of time constraints, and if so they should have waited, IMO. Edit: For anyone interested I just posted a tip that solves this problem. How To Get A Collection Element Type Using Reflection in C#[^]Real programmers use butterflies
Hopefully it will be all fixed in .net5! :rolleyes:
Exception up = new Exception("Something is really wrong."); throw up;
-
Hopefully it will be all fixed in .net5! :rolleyes:
Exception up = new Exception("Something is really wrong."); throw up;
There's little to fix. :sigh: The problem I think, is backward compatibility. I mean, I suppose they could rewrite the CodeDOM in a new System assembly but I think they'd be more likely to retire it, if anything.
Real programmers use butterflies
-
I agree. V1 should never have seen the light of day. And sub-teams working on different areas should have communicated, and there should have been a core team to determine commonalities. I mean, seriously!? :wtf:
public ArgumentException (string message, string paramName);
public ArgumentOutOfRangeException (string paramName, string message);
public ArgumentNullException (string paramName, string message);Amen!
Real programmers use butterflies
-
Hopefully it will be all fixed in .net5! :rolleyes:
Exception up = new Exception("Something is really wrong."); throw up;
-
There's little to fix. :sigh: The problem I think, is backward compatibility. I mean, I suppose they could rewrite the CodeDOM in a new System assembly but I think they'd be more likely to retire it, if anything.
Real programmers use butterflies
I like the CodeDOM and use it a lot, since it is built in.
Exception up = new Exception("Something is really wrong."); throw up;
-
I like the CodeDOM and use it a lot, since it is built in.
Exception up = new Exception("Something is really wrong."); throw up;
I use it quite a bit myself. At the risk of advertising here you might be interested in my project: CodeDOM Go Kit: The CodeDOM is Dead, Long Live the CodeDOM[^] It's quite powerful. It even allows you to parse a C# subset into the CodeDOM so you can construct CodeDOM graphs using C# code, which saves a lot of typing. It allows you to query a CodeDOM tree, and even can perform complex operations on CodeDOM trees like reflection and method selection.
Real programmers use butterflies
-
I agree. V1 should never have seen the light of day. And sub-teams working on different areas should have communicated, and there should have been a core team to determine commonalities. I mean, seriously!? :wtf:
public ArgumentException (string message, string paramName);
public ArgumentOutOfRangeException (string paramName, string message);
public ArgumentNullException (string paramName, string message);Diversity is our strength!
Robust Services Core | Software Techniques for Lemmings | Articles
-
I'm still waiting for, "the framework which is to come after .net" .
.net++ That'd be .neu (new in German)!
Robust Services Core | Software Techniques for Lemmings | Articles
-
Diversity is our strength!
Robust Services Core | Software Techniques for Lemmings | Articles
"Keep 'em guessing" supports the training industry.
-
Because 1.x existed prior to generics we have issues of legacy object models not implementing
IList<T>and instead simply exposing hard typed indexer properties. Normally, you'd just get the generic parameters of the genericIEnumerable<T>interface, but because some object trees were created prior to 2.0 - like the CodeDOM they don't have them. This makes determining the element type of a typed list extremely difficult. The problem is that your alternative is the indexer property which isn't a member of a hard interface, so you have to select the appropriate indexer property from the properties on that type. There might bethis[string name]in there too, for example. There is no contract however, so there are no guarantees. This isn't especially robust. Which means, the obvious solution is to first try to get it using the generic interfaces, and if they aren't available, then we fall back to the less robust method above. This is not ideal, and it requires maybe a page of code to handle all the scenarios. Microsoft didn't put generics into 1.x I think because of time constraints, and if so they should have waited, IMO. Edit: For anyone interested I just posted a tip that solves this problem. How To Get A Collection Element Type Using Reflection in C#[^]Real programmers use butterflies
I've heard that .Net is largely inspired by Java. If the first version of .Net did not have generics, then perhaps Java also did not have generics at that time. How is Java managing its deprecation of features?
-
I've heard that .Net is largely inspired by Java. If the first version of .Net did not have generics, then perhaps Java also did not have generics at that time. How is Java managing its deprecation of features?
Amarnath S wrote:
How is Java managing its deprecation of features?
Java isn't a thing anyone should emulate.
Real programmers use butterflies
-
I agree. V1 should never have seen the light of day. And sub-teams working on different areas should have communicated, and there should have been a core team to determine commonalities. I mean, seriously!? :wtf:
public ArgumentException (string message, string paramName);
public ArgumentOutOfRangeException (string paramName, string message);
public ArgumentNullException (string paramName, string message);Do you mean there are three argument Exceptions (which I can understand) or that message and paramName are switched in two of them? :~
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
I've heard that .Net is largely inspired by Java. If the first version of .Net did not have generics, then perhaps Java also did not have generics at that time. How is Java managing its deprecation of features?
IIRC, Java generics are fundamentally different than .NET ones because they use type erasure, whereas .NET creates specialised variants of generic interfaces. This does give Java more backward compatibility than C#
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
Do you mean there are three argument Exceptions (which I can understand) or that message and paramName are switched in two of them? :~
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
I suspect option 2. :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Because 1.x existed prior to generics we have issues of legacy object models not implementing
IList<T>and instead simply exposing hard typed indexer properties. Normally, you'd just get the generic parameters of the genericIEnumerable<T>interface, but because some object trees were created prior to 2.0 - like the CodeDOM they don't have them. This makes determining the element type of a typed list extremely difficult. The problem is that your alternative is the indexer property which isn't a member of a hard interface, so you have to select the appropriate indexer property from the properties on that type. There might bethis[string name]in there too, for example. There is no contract however, so there are no guarantees. This isn't especially robust. Which means, the obvious solution is to first try to get it using the generic interfaces, and if they aren't available, then we fall back to the less robust method above. This is not ideal, and it requires maybe a page of code to handle all the scenarios. Microsoft didn't put generics into 1.x I think because of time constraints, and if so they should have waited, IMO. Edit: For anyone interested I just posted a tip that solves this problem. How To Get A Collection Element Type Using Reflection in C#[^]Real programmers use butterflies
honey the codewitch wrote:
Microsoft didn't put generics into 1.x I think because of time constraints, and if so they should have waited, IMO.
.net was so radically different with so many improvements, the fact that generics wasn't included was pretty irrelevant. To put things into perspective, .net 1 shipped with email classes that were just an interop wrapper to the CDONTS COM object. If there was no native support for things as fundamental as email, is it any wonder there were no generics? For things like List<T> we just used CollectionBase. There's no major need to programatically determine the underlying collection type...back then or now, it's a fringe requirements that might be important to you, but not the masses, and delaying the rollout of .net for something no-one really needs would not be a good idea.
-
I agree. V1 should never have seen the light of day. And sub-teams working on different areas should have communicated, and there should have been a core team to determine commonalities. I mean, seriously!? :wtf:
public ArgumentException (string message, string paramName);
public ArgumentOutOfRangeException (string paramName, string message);
public ArgumentNullException (string paramName, string message);1.x was just "beta" to play around with, it was never intended for production code, but *hands up* the company I worked for at the time did indeed use it in production. We used sockets a fair bit to communication with UNIX systems and also with banking applications, and .net had socket classes built in so we were keen to migrate to it ASAP.
-
Because 1.x existed prior to generics we have issues of legacy object models not implementing
IList<T>and instead simply exposing hard typed indexer properties. Normally, you'd just get the generic parameters of the genericIEnumerable<T>interface, but because some object trees were created prior to 2.0 - like the CodeDOM they don't have them. This makes determining the element type of a typed list extremely difficult. The problem is that your alternative is the indexer property which isn't a member of a hard interface, so you have to select the appropriate indexer property from the properties on that type. There might bethis[string name]in there too, for example. There is no contract however, so there are no guarantees. This isn't especially robust. Which means, the obvious solution is to first try to get it using the generic interfaces, and if they aren't available, then we fall back to the less robust method above. This is not ideal, and it requires maybe a page of code to handle all the scenarios. Microsoft didn't put generics into 1.x I think because of time constraints, and if so they should have waited, IMO. Edit: For anyone interested I just posted a tip that solves this problem. How To Get A Collection Element Type Using Reflection in C#[^]Real programmers use butterflies
honey the codewitch wrote:
Microsoft didn't put generics into 1.x I think because of time constraints, and if so they should have waited, IMO.
IIRC they couldn't wait because they'd lost the lawsuit with Sun over J++; and needed to get a nominal replacement stack out asap.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
1.x was just "beta" to play around with, it was never intended for production code, but *hands up* the company I worked for at the time did indeed use it in production. We used sockets a fair bit to communication with UNIX systems and also with banking applications, and .net had socket classes built in so we were keen to migrate to it ASAP.
At a previous employer I maintained a .net 1.1 winform app from 05-08. (Other people wrote the initial version in 04 before I started.) We couldn't upgrade to a newer version initially because the customer still had NT4 boxes at some sites; which couldn't run .net 2.0. :sigh: On the plus side the beige NT4 tower stuck in the back corner of my cube gathering dust was my justification for having N+1 monitors for years. (With the +1 spending 99% of its time connected to my main computer.)
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
