SWIFT采用Smalltalk关键字语法的奇案

2020-06-14 21:41:07

得知SWIFT最近采用了Smalltalk关键字语法:[接受]SE-0279:多个尾随闭包,我非常惊讶。也就是说:关键字以冒号结尾,后跟参数,不带任何大括号。令人难以置信。一点。当然,如果这不是特殊情况的特例,特别是多个尾随闭包的特例,这是尾随闭包的一个特例,那么SWIFT就不会成为SWIFT,这是奇怪和特殊的-Casey本身就足够了。下面是一个示例:请注意Animate()的参数似乎在结束括号处终止,但事实并非如此。结束Paren之后的花括号开始了一个闭包,该闭包实际上也是该方法的一个参数,即所谓的尾部闭包。我对这个构造有一点同情,因为圆括号内的闭包看起来真的很别扭。(当然,f(X)中除了唯一的x之外的所有参数看起来都很别扭,但我们不要吹毛求疵。目前。)。这使得另一件事是方法合理地类似于控制结构,我听说这是一个非常好的想法。问题是,有时您有多个闭包参数,然后只是将它们堆叠在函数/方法调用的末尾,这会非常非常尴尬,而且您无法区分哪个块是哪个参数,因为尾随的闭包没有得到关键字。嗯,现在是这样了。我们现在将4种不同的方法语法放在一起!这是令人印象深刻的,以一种可怕的方式。SWIFT是一种特殊情况的发展趋势,其结果是语义上的复杂性、行为上的复杂性(即错误)和使用上的复杂性(即变通方法)。

我明白这项提议颇具争议性,反对者和支持者之间进行了激烈的讨论。我理解并同情双方。一方面,这明显好于其他选择。另一方面,这是一个特殊情况的特殊情况,很难证明它是对已经存在的所有东西的补充。特殊情况产生特殊情况,特殊情况产生特殊情况。当然答案总是存在的:在这种情况下,SmallTalk关键字语法不仅是唯一合理的解决方案,它还可以解决所有其他情况。这是一般的解决方案。在这里可以看到Objective-Smalltalk(它使用花括号代替Smalltalk的方括号来表示闭包):没有特殊情况,每个参数都有标签,括号内没有语法杂乱等等。是的,这也处理用户定义的控制结构,to:do:只是NSNumber上的一个方法:而且由于关键字自然位于它们的参数之间,因此不需要将运算符作为。您只需允许一些";BINARY&34;关键字看起来稍有不同,所以不是2乘:3,而是2*3。当您有2个提升到:3而不是POW(2,3)(带有签名:函数幂(_x:decimal,_y:int)->;Decimal)时,是否真的需要不厌其烦地定义";运算符";?或者是SWIFT的a as b,这是另一种特殊的语法。A、A、B怎么样?(是的,我知道有细节,但这些都是……。详细信息。)。以此类推。当然,现在已经太晚了。当我选择Smalltalk作为已经变成Objective-Smalltalk的语言的基本语法时,不仅仅是因为我喜欢它或者已经通过Objective-C习惯了它。SmallTalk的语法出奇地灵活和通用,Smalltalk API看起来很像DSL,没有任何工具或其他开销。这就是令人沮丧的部分:这些东西过去和现在都是可以买到的,而且是众所周知的。至少如果你不厌其烦地看和/或问一下。相反,我们只是随意地选择这些东西,每个人都要承受后果。