看"c#事件背后臃肿的设计哲学"一帖后随便说说

标题中提到的帖子在这里:
http://www.cnblogs.com/firelong/archive/2010/07/01/1769550.html

回复实在太长,看了一部分,印象中有一类评论是这样的:
"按LZ那样,那不要foreach了,class也不要了,你就用C写得了"

此类语句定是没有理解LZ提出的几点理由
LZ也没说干脆用C写比较好,不过是说event什么的不怎么样罢了

什么样的东西该成为所谓的'语言特性'?,语言的职责是什么?语言不该提供什么?
虽然我不熟悉c# event(从来不使用它),不过至少我认为让语言拥有关于事件的概念这个设计不怎么样
关于foreach,作为一颗糖,不错,当然,它也就是一颗糖

作为一个很本原的考虑,语言应该提供表达力,不提供功能(比如对如BASIC之类的'语言'提供了PRINT作为关键字(!!!),你认为怎么样呢?当然,它有它的诞生背景,所以你可能直接就将它与C之类的语言看作两类东西-_-)
将功能将由库来提供,而语言特性..

(..说到这怎么感觉有些偏题了-_-!,我并不知道是不是有人都将event,foreach之类的东西以'语言特性'来称呼..)
(不管了,继续)

..而语言特性该提供由库(这里'库'基本是'语言使用者编写的代码'的代名词)不可能提供的那些东西——那些库描述不了的(事实上,库是基于它工作的)东西(注意,这个条件自然会将功能性的东西划归到语言的职责以外),如此才能发挥乘法效应,使程序员能用语言做相当强大的事
当然,不是说语法糖没意思,只是它不能影响语言的主体,语言的主体应该有一套良好的基础设施,使得语言的使用者的合理的表达需求(大多)都能被满足

event这么个sophisticated的概念竟然直接出现在语言的对象模型当中,而又并没有带来可观的强大功能,不喜欢..正如原帖LZ所说,非通用性的概念(关键抽象),直接出现在语言里..foreach还好说,event么..
再说说foreach,对于一般需要来说还是不错的,不过,限制却也很厉害.比如:
你要在遍历时数数怎么办
我要跳过第一个元素怎么办
这两个场合显然并非有意为难可爱的foreach,是相当友好的两个例子,但很容易发现,一旦你需要为一个已经用foreach写好的过程适应这两个例子中出现的变化,你就开始考虑放弃foreach,自己干所有的事了!(第一个不说了,比如第二个,你会考虑,使用一个bool来记住是不是正在第一个元素?然后觉得不太好,因为这样凭空给每次多了个判断,然后考虑在循环外处理掉第一个元素,不过立即发现这更糟:你要把处理元素逻辑在循环体前和循环体内各写一遍(!!!))
还有更高级的情景:如果我需要对两个Enumerable作交错的遍历呢?等等

语言特性之为语言特性,它本该在它该在的地方发挥它的威力,而不必不时到库的工作室里去串个小门帮个小忙——同样时间的劳动,呆在它自己的工作室里它可能发挥10倍的威力

顺便,foreach,using之类的东西,将语言和库联系得过于紧密了(即使是对于所谓语言标准库)

最后..foreach,using之类的不能叫语言特性吧..我为什么一直这样称呼它呢-_-!

PS:
那么什么样的东西才是特别值得的?
在这里,比如真正地支持yield
在提供了通用的coroutine语义之外,再给出(如果选择给出的话)foreach糖,那会合理些,而现在是直接来了个foreach,看着真有点如履薄冰的意思..