Yukon和.NET 2.0愿望清单 [英] Yukon and .NET 2.0 Wishlist
问题描述
以下是一些我一直认为应该实施的戏剧性要求。
1）统一无效。我希望.NET能够为所有空值实现统一值
。甚至进入数据库（尤其是关于可以在Yukon做什么的一些炒作）。在将其作为一个
荒谬的声明传递之前，它可以完成并且会简化代码
。对我来说，这是人们只是简单地讨论这些事情之一。不要认为这个问题永远无法解决，因此根本没有需要它。我的意思是，我们研究了如何解决这个问题的不同方法，并发现了许多有趣的方法。一个人为每种数据类型编写了引用类型
类，并添加了一个IsNull属性。这显然可以杀死
效率。我们所做的是使用int.MinValue，
DateTime.MinValue等来表示空值。 DBNull.Value'具有
以特定方式处理以及null'等等...我知道
解决这个问题极其困难并且可能需要付出代价，但个人而言，我不认为是高级语言（例如VB.NET，C＃，
VB 6.0等）应该处理这个问题。这应该是在装配级别处理的
。也许每个值类型可以在
存储空间中加倍（因为硬件和内存变得越来越便宜）并且
第一位可以表示空值。或者，当声明变量时，内存管理器可以将
存储在堆栈中。 Yada Yada
Yada ...
2）由于许多与＃1相同的原因（＃1是＃2的一个子集），
为什么SQL Server和.NET不能有统一的类型。这真的是现在推动它（我知道）并且可能不会很快发生
（尽管Yukon可能会朝这个方向迈进）。我知道这是一个很大的转变，会导致很多东西中断，但是正确的做法是让b / b
做正确的事情并使代码中的错误更少董事会。
例如，十进制，货币，货币，日期时间，小时，位，
布尔值，特别是空值（＃1）。
3）自动创建内置于Visual
Studio中的解决方案构建订单。我想的越多，我就越相信这将是一个非常简单的附加组件。来写。微软拒绝这样做
并且会让我认为许多人的生活变得更加轻松。在
中简称这意味着你应该能够在一个解决方案中添加15个
项目，然后点击一个按钮就可以了解
您的构建顺序取决于每个项目的引用。 Visual
Studio包含解决方案构建顺序，但问题是你需要手动设置此列表。
每当有变化时（例如，在项目内部添加新项目或参考项目更改），您需要相应地更新此列表。
必须更新此列表。对于
单个项目中的参考路径，如果你有（如果你需要在内部有多个参考路径，这只会成为一个问题）
那个项目）。我确实认为有必要允许用户手动执行它，但是这也是一个巨大的补充。
4）所有数组都应该从1开始！这是（对我来说）遗产的遗产并且不会消失（可能永远）。确实没有必要使用基于零的数组。我们现在使用高级语言，所以我们应该处理逻辑！
我认为这么多人坚持基于零的数组的概念的原因是它让他们感觉像是c ++的一部分。人群而不是VB的一部分。人群中，很多人都认为c ++需要更多的技能。 （我确实认为这是最大的原因）。无论如何，我对此的认识与任何
特定语言无关。我精通c＃，VB.NET，VB 6.0和C ++ 6.0所以
我根本没有偏见。我的意思是，让我们面对现实吧：如果一个数组中有3个项目
，那么Count = 3你可以引用最后一项如
这个数组[array.Count]这对我来说是完全符合逻辑的。
Dave
malcolm< ch ********@yahoo.com>写道：这里有一些我一直认为应该实现的戏剧性要求。
1）统一无效。我希望.NET能够为所有空值实现统一的值。甚至进入数据库（特别是关于Yukon可以做什么的一些炒作）。在将其作为一个荒谬的声明传递之前，它可以完成并且会极大地简化代码。对我来说，这是人们只是简单地认为这个问题永远无法解决的事情之一，因此根本不需要它。我的意思是，我们研究了如何解决这个问题的不同方法，并找到了许多有趣的方法。一个人为每种数据类型编写了引用类型
类，并添加了一个IsNull属性。这显然有效杀死了效率。我们所做的是使用int.MinValue，
DateTime.MinValue等来表示空值。 DBNull.Value'有待以特定的方式处理以及null'等等......我知道要解决这个问题极其困难并且可能需要付出代价，但是
就个人而言，我不认为高级语言（如VB.NET，C＃，VB 6.0等）应该处理这些问题。这应该在装配级别处理。也许每种值类型可以在存储空间中加倍（因为硬件和内存变得越来越便宜）并且
第一位可以表示空值。或者，当声明变量时，内存管理器可以将该位存储在堆栈中。 Yada Yada
Yada ...
所以你说的是一个字节不再能够持有
256个不同有效值？在阅读文件等时，这会让事情变得有趣
...
或者您是否建议字节类型不再仅占用8
位？
4）所有数组应从1开始！这是（对我而言）遗产并且不会消失（可能永远）。确实不需要基于零的阵列。
IMO也不需要基于单一的阵列。
我们现在使用的是高级语言，所以我们应该
处理逻辑！我认为这么多人坚持零基数组概念的原因在于它让他们感觉像是c ++的一部分。人群而不是VB的一部分。人群，很多人认为c ++需要更多的技能。
不，我认为与使用C＃的大量C / C ++ / Java
开发人员有更多关系基于0的条款
数组。我知道我这样做......
（我确实认为这是最大的原因）。无论如何，我对此的认识与任何
特定语言无关。我擅长c＃，VB.NET，VB 6.0和C ++ 6.0所以
我根本没有偏见。我的意思是，让我们面对现实吧：如果一个数组中有3个项目，那么Count = 3就可以引用最后一项如
这个数组[array.Count]这完全是对我来说是合乎逻辑的。
当然，如果你真的想要
，你可以使用Array类的下限为1。 br />
-
Jon Skeet - < sk *** @ pobox.com>
http://www.pobox.com/~skeet
如果回复小组，请执行不要给我发邮件
" malcolm" < CH ******** @ yahoo.com>在消息中写道
新闻：4f ************************** @ posting.google.c om ...以下是一些我一直认为应该实施的戏剧性要求。
1）统一无效。我希望.NET能够为所有空值实现统一的值。甚至进入数据库（特别是关于Yukon可以做什么的一些炒作）。在将其作为一个荒谬的声明传递之前，它可以完成并且会极大地简化代码。对我来说，这是人们只是简单地认为这个问题永远无法解决的事情之一，因此根本不需要它。我的意思是，我们研究了如何解决这个问题的不同方法，并找到了许多有趣的方法。一个人为每种数据类型编写了引用类型
类，并添加了一个IsNull属性。这显然有效杀死了效率。我们所做的是使用int.MinValue，
DateTime.MinValue等来表示空值。 DBNull.Value'有待以特定的方式处理以及null'等等......我知道要解决这个问题极其困难并且可能需要付出代价，但是
就个人而言，我不认为高级语言（如VB.NET，C＃，VB 6.0等）应该处理这些问题。这应该在装配级别处理。也许每种值类型可以在存储空间中加倍（因为硬件和内存变得越来越便宜）并且
第一位可以表示空值。或者，当声明变量时，内存管理器可以将该位存储在堆栈中。 Yada Yada
Yada ...
应该有一个泛型类型，Nullable< T>我认为，这可以处理
。它类似于其他地方提供的可空类型。加倍
内存大小只是因为null-ness是愚蠢的，值类型永远不应该是
null无论如何，这是不对的。无论如何，作为一个整体，.NET永远不会改变值类型的语义，但是Nullable< T>应该允许你做你需要的
。
有理由不允许null（例如，没有这样的东西
作为一个零数字，虽然有NaN'，NaT'或其他什么）和我
个人认为它是一个有效的概念。 2）由于许多与＃1相同的原因（＃1是＃2的一个子集），为什么SQL Server和.NET不能有统一的类型。这真的是推动它（我知道）并且可能不会很快发生
（尽管育空可能会朝这个方向迈进）。我知道这是一个巨大的转变，并且会导致许多东西被打破，但这将是正确的做法，并使代码在整个董事会中有更少的错误。
例如，十进制，钱，货币，DateTime，SmallTime，位，布尔值，特别是空值（＃1）。
数据库中的空格有时是邪恶的东西，但它们是nessecery。 br />
这并不意味着价值类型需要它们。我也不知道它是否有意义
将金钱，货币，比特，SmallTime等添加到框架中。 3）自动创建Visual
Studio内置的解决方案构建顺序。我越是想到它，我越相信这将是一个非常简单的附加组件。来写。微软拒绝这样做，并且会让我认为许多人的生活变得更加容易。简而言之，这意味着您应该能够在解决方案中添加15个项目，然后单击一个按钮，它会根据每个项目的引用确定构建顺序。项目。 Visual
Studio包含解决方案构建顺序，但问题是您必须手动设置此列表。每当有变化时（例如在项目内部添加新项目或参考更改），您必须相应地更新此列表。如果你有（如果你需要在项目内部有多个参考路径，这只会成为一个问题），那么对于单个项目中的
参考路径也是如此。我确实认为需要允许用户手动操作
，但我认为这将是一个巨大的补充。
我不明白你的问题在这里。我没有任何真正的问题与
构建订单，VS通常根据依赖性很好地组织它。 4）所有数组应从1开始！这是（对我而言）遗产并且不会消失（可能永远）。确实不需要基于零的阵列。我们现在使用高级语言，所以我们应该处理逻辑！我认为这么多人坚持零基数组概念的原因在于它让他们感觉像是c ++的一部分。人群而不是VB的一部分。人群，很多人认为c ++需要更多的技能。 （我确实认为这是最大的原因）。无论如何，我对此的认识与任何
特定语言无关。我擅长c＃，VB.NET，VB 6.0和C ++ 6.0所以
我根本没有偏见。我的意思是，让我们面对现实吧：如果一个数组中有3个项目，那么Count = 3就可以引用最后一项如
这个数组[array.Count]这完全是对我来说是合乎逻辑的。
嘿，我仍然认为参数是BS，你传递给数组的值是
* offset *而不是其顺序位置的标签。当我传递一个数组0它
意味着我希望项目在偏移0处，而不是我想要项目*数字* 0.
a在插槽计数方面有显着差异偏移。然而，这也可以永远不会改变，它为.NET的重复生活奠定了基础。
Dave
> 4）所有阵列都应该从1开始！
大多数时候我必须经历所有数组的项目，
所以我更喜欢写了
for（int i = 0; i< Array.Length; i ++）
然后
for（int i = 1; i< = Array.Length; i ++）
或
for（int i = 1 ; i< Array.Length + 1; i ++）
...我的意思是，让我们面对它：如果一个数组有3个项目
在它，然后Count = 3你可以引用最后一项像
这个数组[array.Count]这对我来说是完全符合逻辑的。
您多久需要引用一个数组的最后一项？
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 <ch********@yahoo.com> wrote: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...
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.
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.
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.
Of course, you can use the Array class to have a lower bound of 1 if
you really want.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"malcolm" <ch********@yahoo.com> wrote in message
news:4f**************************@posting.google.c om...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...
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).
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.
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.
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.
Dave
> 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.
How often do you need to refer the last item of an array?
这篇关于Yukon和.NET 2.0愿望清单的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
