Here are a couple of dramatic requests that I've always thought should
be implemented.
1) Uniform null. I wish .NET would implement a uniform value for nulls
accross the board. Even into the database (especially with some of the
hype about what can be done in Yukon). Before passing this off as an
absurd statement, it could be done and would simplify code
dramatically. To me, it's one of those things that people just simply
don't think this could ever be solved so there is simply no demand for
it. I mean, we did research on different methods on how to solve this
and found many interesting approaches. One guy wrote reference type
classes for each datatype and added an IsNull property. This kills
effeciency though obviously. What we do is use int.MinValue,
DateTime.MinValue, etc to represent a null value. DBNull.Value's have
to be handled in a specific way as well as null's etc... I know to
solve this would be extremly difficult and may come at a cost, but
personally, I don't think a high level language (such as VB.NET, C#,
VB 6.0, etc) should have to deal with this stuff. This should be
handled at the assembly level. Maybe each value type could double in
storage space (since hardware and memory is becoming cheaper) and the
first bit could represent a null value. Or the memory manager could
store the bit on the stack when the variable is declared. Yada Yada
Yada...
2) For many of the same reasons as #1 (#1 is kind of a subset of #2),
why can't SQL Server and .NET have uniform types. This is really
pushing it now (I know) and probably will not happen anytime soon
(although Yukon may make steps towards this). I know this is a
drastic shift and would cause a lot of stuff to break, but it would be
the right thing to do and make code have less bugs accross the board.
For example, decimal, money, currency, DateTime, SmallTime, bit,
boolean and especially nulls (#1).
3) Automated creation of Solution Build Order built into Visual
Studio. The more I think about it, the more I'm convinced that this
would be a pretty easy "Add-On" to write. Microsoft refused to do this
and would have made many peoples lives a whole lot easier I think. In
short what this would mean is that you should be able to add 15
projects to a solution and then click on a button and it figures out
your build order depending on the references of each project. Visual
Studio includes a Solution Build Order but the problem is that you
have to set this list manually. And whenever there is a change (such
as adding a new project or a reference inside a project changing), you
have to update this list accordingly. The same even hold's true for
reference paths inside of a single project if you have (this only
becomes an issue if you need to have multiple reference paths inside
that project). I do see the need to allow the user to manually do it
also, but this would be a huge addition I think.
4) All arrays should start at 1! This is something (to me) that is
legacy and won't go away (probably ever). There really is no need for
zero based arrays. We are in high level languages now, so we should
be dealing with logic! I think the reason so many people stick to the
notion of zero based arrays is that it makes them feel like part of
the "c++" crowd and not part of the "VB" crowd, where many people
think c++ requires more skills. (I really do think this is the biggest
reason). Anyway, my thougths on this have nothing to do with any
particular language. I'm skilled in c#, VB.NET, VB 6.0 and C++ 6.0 so
I'm not biased at all. I mean, let's face it: If an array has 3 items
in it, then the Count = 3 and you can reference the last item like
this array[array.Count] which is completely logical to me.
Dave
