Yukon and .NET 2.0 Wishlist

  • Thread starter Thread starter malcolm
  • Start date Start date
M

malcolm

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
 
malcolm said:
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...
Click to expand...

So what you're saying is that a byte should no longer be able to hold
256 different valid values? That's going to make things interesting
when reading files, etc...

Or were you proposing that the byte type no longer takes up only 8
bits?
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.
Click to expand...

There's no need for one-based arrays either, IMO.
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.
Click to expand...

No, I think it's far more to do with there being lots of C/C++/Java
developers using C# who think more naturally in terms of 0-based
arrays. I know I do...
(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.
Click to expand...

Of course, you can use the Array class to have a lower bound of 1 if
you really want.
 
malcolm said:
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...
Click to expand...
There is supposed to be a generic type, Nullable<T> I think, that handles
this. It is similar to the nullable types provided elsewhere. Doubling
memory size simply for null-ness is silly and value types should never be
null anyway, that just isn't right. Anyway, as a whole, .NET can never
change the semantics of value types, but Nullable<T> should allow you to do
what you need to.
There are reasons for not allowing null(for example, there is no such thing
as a null number, although there are NaN's, NaT's, or whatever) and I
personally think its a valid concept.
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).
Click to expand...
Nulls in a database are sometimes an evil thing, but they are nessecery.
That doesn't mean value types need them. I also don't know if it makes sense
to add money, currency, bit, SmallTime etc to the framework.
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.
Click to expand...
I don't understand your problem here. I have not had any real issue with
build orders, VS generally organizes it quite nicely based on dependences.
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.
Click to expand...
Heh, I still think that argument is BS, the value you pass to an array is an
*offset* not a label of its sequential position. When I pass an array 0 it
means I want the item at offset 0, not that I want Item *number* 0. There is
a significant difference in slot counting and offsets. However, this too can
never change, its set in stone for the remaning life of .NET.
 
4) All arrays should start at 1!

Most of the time I have to go through all the array's items,
so I prefer to write

for (int i=0;i<Array.Length;i++)

then

for (int i=1;i<=Array.Length;i++)

or

for (int i=1;i<Array.Length+1;i++)

... 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.
Click to expand...

How often do you need to refer the last item of an array?
 
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.
Click to expand...

I heard a couple years ago, that VB is language made by non-programmers
for programmers. Do not offend. But you should be pleased, that
you can choose between languages. And you should not
demand such a change becasue 0 based array are very useful.
Consider modulo(%).

Gawel
 
zero based arrays are useful? Why?

You can use the .Count property of the Array and you can also test for NULL.

Off by one is a very common bug and we have yet to fix the cause, The fault
is inherent in the design of C#.



Gawelek said:
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.
Click to expand...

I heard a couple years ago, that VB is language made by non-programmers
for programmers. Do not offend. But you should be pleased, that
you can choose between languages. And you should not
demand such a change becasue 0 based array are very useful.
Consider modulo(%).

Gawel
Click to expand...
 
zero based arrays are useful? Why?

You can use the .Count property of the Array and you can also test for NULL.
Click to expand...

I'm not sure what the relevance of your comments about Count and null
testing is...
Off by one is a very common bug and we have yet to fix the cause, The fault
is inherent in the design of C#.
Click to expand...

I can't remember the last time I encountered an off-by-one bug due to
arrays being 0-based - although I'm sure that if they suddenly became
1-based instead, it would *then* be a common bug for me.
 
Yes because you are so perfect.

Everybody does the Count-1 check every time after sitting hours in front of
a computer.

Its not representitive of the REAL WORLD starting at zero indexing which is
what we are providing solutions for.

Off by one never happens, thats why its even got a name.
 
Yes because you are so perfect.
Click to expand...

No, because I'm used to it one particular way - as I believe many users
of C# are. (All of those with a C/C++/Java background, for starters.)
VB users happen to be used to it a different way.
Everybody does the Count-1 check every time after sitting hours in front of
a computer.
Click to expand...

Well, I can't remember the last time I had an off by one error caused
by array indexing starting at zero. (Various other types of off by one
error, yes, but not to do with array indexing.)
Its not representitive of the REAL WORLD starting at zero indexing which is
what we are providing solutions for.
Click to expand...

Well I for one am perfectly happy providing solutions using zero-based
arrays. From the other replies, it seems I'm not the only one either.
As a mathematician and a computer scientists, I'm just as happy
counting from 0 as from 1 - and mathematical concepts typically *do*
start with 0 rather than 1. Whether you count mathematical research and
modelling as the real world or not is up to you, but it's the real
world as far as an awful lot of people are concerned.
Off by one never happens, thats why its even got a name.
Click to expand...

Did I suggest that it never happens? No. I suggested that I find it's
pretty rare - and that it would be made worse, not better, by changing
to a base 1 system - for me.
 
People accept it because its legacy and are afraid of change, its like this
to win over the C/C++ developers.

Its not representitive of the real world scenario.

The first item is just that , FIRST item (NUMBER 1), not number 0.
 
People accept it because its legacy and are afraid of change, its like this
to win over the C/C++ developers.

Its not representitive of the real world scenario.
Click to expand...

It's not representative of *some* real world scenarios. It's
representative of other things which are being modelled in computing.
The first item is just that , FIRST item (NUMBER 1), not number 0.
Click to expand...

Yes, for some kinds of mapping of number to item, that's true. It's not
true of all mappings, however - many are naturally from 0.
 
A collection, I have a collection of holes in front of me, I want the first
item from that collection.

I INSTINCTIVELY pick the FIRST hole!

I dont see a ZEROth hole.
 
A collection, I have a collection of holes in front of me, I want the first
item from that collection.

I INSTINCTIVELY pick the FIRST hole!

I dont see a ZEROth hole.
Click to expand...

That doesn't disprove my point at all - it just confirms what I've said
about there being *some* (many, even) models where mapping naturally
starts from 1. It in no way contradicts what I said, which is that
there are other models where mapping starts from 0.

There are various other ways in which arrays beginning with 0 make more
sense. For instance, take a mapping from (x, y) to a value. It's easy
to use

value = map[x+y*rowSize];

That's natural for 0-based co-ordinates (which are normal in maths).
You'd have to add one for 1-based arrays. If you also want to use 1-
based co-ordinates (to avoid having two different bases) you'd then
need something horrible such as:

value = map[x+(y-1)*rowSize];
 
Yes and in my arrse its using -1 indexing.


Jon Skeet said:
A collection, I have a collection of holes in front of me, I want the first
item from that collection.

I INSTINCTIVELY pick the FIRST hole!

I dont see a ZEROth hole.
Click to expand...

That doesn't disprove my point at all - it just confirms what I've said
about there being *some* (many, even) models where mapping naturally
starts from 1. It in no way contradicts what I said, which is that
there are other models where mapping starts from 0.

There are various other ways in which arrays beginning with 0 make more
sense. For instance, take a mapping from (x, y) to a value. It's easy
to use

value = map[x+y*rowSize];

That's natural for 0-based co-ordinates (which are normal in maths).
You'd have to add one for 1-based arrays. If you also want to use 1-
based co-ordinates (to avoid having two different bases) you'd then
need something horrible such as:

value = map[x+(y-1)*rowSize];
Click to expand...
 
I heard internally they battled over zero or 1 base too for a while.
Personally, I remember back in VB when you had to choose when you created
the array (IIRC). I always got confused thinking which way to go. I like
the zero based because its always the same, and you can deal with it and
your remember the gotchas from last statement you did. It probably all goes
back to bit addressing where the first low bit is bit 0 (not sure) I have
gotten fond of things like "for(int i=0; i < array.length; i++)", but you
can get used to anything I guess - just stick with one way if possible.

--
William Stacey, MVP

A collection, I have a collection of holes in front of me, I want the first
item from that collection.

I INSTINCTIVELY pick the FIRST hole!

I dont see a ZEROth hole.
Click to expand...
 
Youi like it because you are used to it. Legacy.


William Stacey said:
I heard internally they battled over zero or 1 base too for a while.
Personally, I remember back in VB when you had to choose when you created
the array (IIRC). I always got confused thinking which way to go. I like
the zero based because its always the same, and you can deal with it and
your remember the gotchas from last statement you did. It probably all goes
back to bit addressing where the first low bit is bit 0 (not sure) I have
gotten fond of things like "for(int i=0; i < array.length; i++)", but you
can get used to anything I guess - just stick with one way if possible.
Click to expand...
 
Not really. At first I thought 1 based, however I like zero now. Most, if
not all Win32 structures are zero based IIRC, and most/all low level stuff
and hw stuff is zero based. Besides, it does not really matter now does it?
We got what we got so make the best of it :-)
 
Back
Top