为什么 viewWithTag 和其他一些方法没有在 Swift 3 中重命名? [英] Why isn't viewWithTag and some other methods renamed in Swift 3?

问题描述

在 Swift 3 中，很多方法被重命名.根据 WWDC 的其中一场会议，方法名称中的介词移至参数名称:

UIView.animateWithDuration(1)->UIView.animate(withDuration: 1)UIStoryboard.instantiateViewControllerWithIdentifier("一些东西")->UIStoryboard.instantiateViewController(withIdentifier:一些东西")

所以我认为 viewWithTag(1) 会被重命名为 view(withTag: 1)，但事实并非如此！

API 指南中甚至提到:

<块引用>

特别是当参数类型是 NSObject、Any、AnyObject 或基本类型(例如 Int 或 String)时，使用时的类型信息和上下文可能无法完全传达意图.在这个例子中，声明可能是明确的，但使用地点是模糊的.

func add(_观察者: NSObject, for keyPath: String)grid.add(self, for: graphics)//模糊

为了清晰起见，在每个弱类型参数前面加上一个描述其作用的名词:

func addObserver(_observer: NSObject, forKeyPath path: String)grid.addObserver(self, forKeyPath: graphics)//清除

我还发现SKNode.addChild也没有重命名！

问题:

为什么这些方法没有重命名?他们忘了他们?或者 API 指南是否有例外情况?如果是，它们是什么?

解决方案

我正在研究 Swift Evolution 0005.

1. viewWithTag

名称修剪的第一步是:

<块引用>

1. 从类型保留转换的头部修剪结果类型.具体来说，当

   • 接收器类型与结果类型相同
   • 并且类型名称在第一个选择器的头部匹配
   • 并且匹配后跟一个介词

view 部分实际上是第一个被删除的部分.

forTag 在第 3 步中也被移除了，因此结果是一个空的选择器.

与

发生冲突<块引用>

修剪限制...

• 永远不要让选择器完全空白.

因此不进行修剪.

2. addChild

addChild, addSubview, addGestureRecognizer 都遵循相同的模式，规范中实际上有一个示例:

<块引用>

• 永远不要从与封闭类的属性匹配的方法的基本名称中删除后缀:

这种启发式方法的作用是防止我们为在概念上修改类属性的方法产生过于通用的名称.

... 如果我们去掉 GestureRecognizer，只留下 add，我们最终会得到一个方法，它在概念上修改了 gestureRecognizers 属性但使用过于通用的名称来这样做:

一般来说，他们不能忘记一些方法，因为重命名(导入)是自动的.

In Swift 3, a lot of the methods got renamed. According to one of the sessions at WWDC, the prepositions in method names are moved to the parameter name:

UIView.animateWithDuration(1)
 -> UIView.animate(withDuration: 1)

UIStoryboard.instantiateViewControllerWithIdentifier("some stuff")
 -> UIStoryboard.instantiateViewController(withIdentifier: "some stuff")

So I thought viewWithTag(1) will be renamed to view(withTag: 1), but it isn't!

There is even mentioned in the API guidelines:

Especially when a parameter type is NSObject, Any, AnyObject, or a fundamental type such Int or String, type information and context at the point of use may not fully convey intent. In this example, the declaration may be clear, but the use site is vague.

func add(_ observer: NSObject, for keyPath: String)
grid.add(self, for: graphics) // vague

To restore clarity, precede each weakly typed parameter with a noun describing its role:

func addObserver(_ observer: NSObject, forKeyPath path: String)
grid.addObserver(self, forKeyPath: graphics) // clear

I also found that SKNode.addChild is not renamed as well!

Question:

Why are these methods not renamed? They forgot about them? Or are there exception cases to the API guidelines? If yes, what are them?

解决方案

I am looking into the algorithm described in Swift Evolution 0005.

1. viewWithTag

The first step of name pruning is:

1. Prune the result type from the head of type-preserving transforms. Specifically, when

   • the receiver type is the same as the result type
   • and the type name is matched at the head of the first selector piece
   • and the match is followed by a preposition

the view part is actually the first to be removed.

The forTag is removed too in step 3, therefore the result is an empty selector.

That collides with

Pruning Restrictions ...

• Never make a selector piece entirely empty.

Therefore no pruning is performed.

2. addChild

addChild, addSubview, addGestureRecognizer follow all the same pattern, there is actually an example in the spec:

• Never prune a suffix from the base name of a method that matches a property of the enclosing class:

This heuristic has the effect of preventing us from producing too-generic names for methods that conceptually modify a property of the class.

... If we were to drop GestureRecognizer, leaving just add, we end up with a method that conceptually modifies the gestureRecognizers property but uses an overly generic name to do so:

In general, they cannot forget about some methods because the renaming (importing) is automatical.

这篇关于为什么 viewWithTag 和其他一些方法没有在 Swift 3 中重命名?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！