在复杂排序中处理optional

本系列文章为个人学习笔记:禁止转载

为optional类型“提升”比较函数

假设,我们有一个表示1到5的[String]

let numbers = ["Five", "4", "3", "2", "1"]

现在,要按照整数比较它们的大小,怎么做呢?显然,用下面的方法创建SortDescriptor<String>是不行的:

let intDescriptor: SortDescriptor<String> =
    makeDescriptor(key: { Int($0) }, <)

我们会得到下面的错误:

[图片上传中...(image-ce04bc-1582028782053-1)]

这是因为,Int($0)返回了Int?,而在Swift 3中,Apple去掉了对optional类型的比较操作,它们认为大家对于optional中,值和nil的比较会引起歧义。但没关系,这并不妨碍我们自己来实现比较optional的过程,一个最直接的手段,就是把比较逻辑直接写在makeDescriptor里:

let intDescriptor: SortDescriptor<String> =
    makeDescriptor(key: { Int($0) }, { l, r in
        switch (l, r) {
        case (nil, nil):
            return false
        case (nil, _):
            return false
        case (_, nil):
            return true
        case let (l?, r?):
            return l < r
        default:
            fatalError()
        }
    })

这个实现没什么难度,我们只是通过若干个case定义了当参与比较的一方或双方都为nil时的比较规则。简单来说就是:

  • 当参与比较的两个值都不为nil时,就用<比较它们的大小;
  • 我们把所有的nil结果放在数组的最后,并且,不对同为nil的结果进行比较;

但是,这样的代码还是无法通过编译,编译器会告诉我们无法推导closure expression的类型.
这是因为,我们的makeDescriptor使用的比较函数,不能接受两个Optional类型的参数。我们需要定义一个方法,把一个(T, T) -> Bool,“提升”成一个(T?, T?) -> Bool就好了:

func shift<T: Comparable>(
    _ compare: @escaping (T, T) -> Bool) -> (T?, T?) -> Bool {
    return { l, r in
        switch (l, r) {
        case (nil, nil):
            return false
        case (nil, _):
            return false
        case (_, nil):
            return true
        case let (l?, r?):
            return compare(l, r)
        default:
            fatalError()
        }
    }
}

这段代码和我们之前在makeDescriptor中使用的逻辑,99%都是相同的,只不过,在lr都不为nil时,我们使用了compare参数来比较它们的大小。

有了这个“提升”函数之后,我们就可以这样来定义intDescriptor

let intDescriptor: SortDescriptor<String> =
    makeDescriptor(key: { Int($0) }, shift(<))

这明显要比之前的版本直观多了,而排序的结果,应该和之前是一样的。

自定义组合排序规则的操作符

在上一节中,我们遗留的第二个问题,是合并多个SortDescriptorcombine方法,暴露了我们本不需要的实现细节。当然,这是我们采取的实现方案不可避免的弊端,但为了让它语法上好看一些,我们可以做一些改进。

例如,用一个自定义的操作符,来表现这种逐层递进的排序关系:

episodes.sorted(by: typeDescriptor |> lengthDescriptor)

这样,我们就不用先定义成数组,然后再combine了。至于|>操作符的实现,核心思想和combine几乎是一样的。

首先,我们要自定义|>操作符:

infix operator |>: LogicalDisjunctionPrecedence

由于要用在两个操作数中间,所以,我们把它定义为了infix operator。另外,由于我们要定义的操作符在语义上,有逻辑上逐层深入的含义,我们还把它的优先级定义为了LogicalDisjunctionPrecedence,也就是说,它和||以及&&的优先级是相同的。如果我们不指定优先级,Swift会为它设置默认的DefaultPrecedence

定义好这个操作符之后,我们就可以来实现它了:

func |><T>(
    l: @escaping SortDescriptor<T>,
    r: @escaping SortDescriptor<T>) -> SortDescriptor<T> {

    return {
        if l($0, $1) {
            return true
        }

        if l($1, $0) {
            return false
        }

        // $0 and $1 is the same, try the second descriptor
        if r($0, $1) {
            return true
        }

        return false
    }
}

看到了吧,|>的核心实现逻辑和上一节中的combine唯一的不同,就是在左操作数比较相等后,我们继续使用了右操作数继续进行比较。

定义好了这个操作符之后,之前串联descriptor的代码也就可以正常工作了:

episodes.sorted(by: typeDescriptor |> lengthDescriptor)

而得到的结果,应该和之前使用combine是一样的。

©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容

  • 这是16年5月份编辑的一份比较杂乱适合自己观看的学习记录文档,今天18年5月份再次想写文章,发现简书还为我保存起的...
    Jenaral阅读 2,894评论 2 9
  • importUIKit classViewController:UITabBarController{ enumD...
    明哥_Young阅读 3,926评论 1 10
  • Hello Word 在屏幕上打印“Hello, world”,可以用一行代码实现: 你不需要为了输入输出或者字符...
    restkuan阅读 3,247评论 0 6
  • 再没有比一群羊更慢的时光了 一片云朵缓缓漂移 这是在一个早晨或者黄昏 阳光斜照过来 那么安静那么亮 湿漉...
    为民的简书阅读 300评论 1 6
  • 今天开始挑战自己一下,能坚持几天算几天吧。 刺眼的阳光里醒来,整个被子上都是阳光,空气里也有一股暖香。我拍拍被子,...
    风_a1a7阅读 208评论 0 1