标签 泛型 下的文章

Go泛型语法又出“幺蛾子”:引入type set概念和移除type list中的type关键字

本文永久链接 – https://tonybai.com/2021/04/07/go-generics-use-type-sets-to-remove-type-keyword

近日,Go泛型语法负责人之一的Ian Lance Taylor发布了一个issue,说明go团队想引入新的type set概念,并去除原Go泛型方案中置于interface定义中的type list中的type关键字。

对于Go泛型来龙去脉不是很了解的童鞋,可以先去看看我看看我之前的文章:《能力越大,责任越大” – Go语言之父详解将于Go 1.18发布的Go泛型》。在那篇文章的结尾,Go设计团队对自己的Go泛型设计方案中的几个方面给出了自己的满意度评价,其中唯一让团队感觉还不是很完美的就是“Type lists in interfaces”:

1. 何为Type lists in interfaces

我们先来说说何为Type lists in interfaces!当前Go泛型方案使用interface类型用于表达对类型参数(type parameters)的约束(constraints),比如:

type MyC1 interface {
    M1()
}

func F1[T MyC1](t T) {

}

在上述代码中,我们使用interface MyC1作为类型参数(type parameters)的约束,对于F1函数而言,所有满足MyC1接口的类型都可以作为其类型参数的实参传入:

type MyT1 string
func(t1 *MyT1) M1() {}

var t1 = new(MyT1)
F1(t1)

*MyT1实现了MyC1接口,于是我们可以将其实例(t1)传给F1。Go泛型的自动类型推导会将T的实参置为*MyT1。

完整程序如下:

// https://go2goplay.golang.org/p/WPCvmwkxcEL
package main

import (
    "fmt"
)

type MyC1 interface {
    M1()
}

func F1[T MyC1](t T) {
    fmt.Printf("%T\n", t)
}

type MyT1 string

func (t1 *MyT1) M1() {

}

func main() {
    var t1 = new(MyT1)
    F1(t1) // *main.MyT1
}

对于自定义类型,通过实现接口的方法集合即可满足接口,对于类型参数可以是原生类型的情况,我们无法通过这种方式实现,于是Go团队将type list加入到interface接口中,仅用作泛型类型参数的约束检查

type MyC2 interface {
    type int, int32, int64
}

func F2[T MyC2](t T) {
    fmt.Printf("%T\n", t)
}

func main() {
    var t2 string
    F2(t2) // string
}

而MyMC2中的:

    type int, int32, int64

就是所谓的”type list”。

如果一个interface定义中既有method也有type list,那么要满足这个interface类型,则作为类型参数实参的类型既必须在type list中(或其underlying type在type list中),又必须实现接口类型的所有方法:

// https://go2goplay.golang.org/p/rE8mGH0lHWm
package main

import (
    "fmt"
)

type MyC3 interface {
    M3()
    type int, string, float64
}

func F3[T MyC3](t T) {
    fmt.Printf("%T\n", t)
}

type MyT3 string

func (t3 MyT3) M3() {

}

func main() {
    t3 := MyT3("hello")
    F3(t3) // main.MyT3
}

细心的童鞋会发现:拥有type list的interface仅能用于做为类型参数的约束,而不能像普通interface类型那样使用:

// https://go2goplay.golang.org/p/mJoEYrceBSL
package main

type MyC3 interface {
    M3()
    type int, string, float64
}

func main() {
    var i3 MyC3 // type checking failed for main
                    // prog.go2:9:9: interface contains type constraints (int, string, float64)
    _ = i3
}

这种gap(缝隙)始终让Go核心团队的开发人员感到“不爽”,那么能否将两者融合在一起呢?即放开对包含type list的interface类型仅能做constraint的限制,让其和普通interface一样使用。这次引入的type set应该是解决这个问题的一个前提。但在这个新proposal中,核心团队还没有将这个问题作为重点,只能算作是为以后留个作业吧。

2. 引入type set概念

Ian Lance Taylor发布的这个issue主要就是想引入type set概念,并用新语法等价替代原泛型proposal中的type list,新语法去除了原type list中的type关键字

于是go团队试图这样来做:

// 当前的type list
type SignedInteger interface {
    type int, int8, int16, int32, int64
}

// type set理念下的新语法
type SignedInteger interface {
    ~int | ~int8 | ~int16 | ~int32 | ~int64
}

我们看到新语法中去掉了原先type list中的type关键字,类型间的间隔也由逗号改为了管道符|。按该proposal的原意,管道符(在布尔代数中也表示或)更接近于type list的原意,即可以是int,或int8或….。如果仅仅是变成了如下改进的语法:

type SignedInteger interface {
    int | int8 | int16 | int32 | int64
}

估计大家也没多大意见。但是偏偏引入了“~”这个前缀。~int与int有什么区别呢?要搞清楚区别就要先来看看Ian新引入的type set概念了。

什么是type set(类型集合)?Ian给出了此概念的定义:

  • 每个类型都有一个type set。
  • 非接口类型的类型的type set中仅包含其自身。比如非接口类型T,它的type set中唯一的元素就是它自身:{T};
  • 对于一个普通的、没有type list的普通接口类型来说,它的type set是一个无限集合。所有实现了该接口类型所有方法的类型都是该集合的一个元素,另外由于该接口类型本身也声明了其所有方法,因此接口类型自身也是其Type set的一员。
  • 空接口类型interface{}的type set中则是囊括了所有可能的类型;
  • 这样一来我们来试试用type set概念重新陈述一下一个类型T实现一个接口类型I:即当类型T是接口类型I的type set的一员时,T便实现了接口I;
  • 对于使用嵌入接口类型组合而成的接口类型,其type set就是其所有的嵌入的接口类型的type set的交集。proposal中的举例:type O2 interface{ E1; E2 } ,则02这个接口类型的type set是E1和E2两个接口类型的type set的交集。
  • 一个拥有一个method的接口类型,比如:
type MyInterface1 interface {
    MyMethod()
}

可以看成嵌入一个仅包含MyMethod的接口类型的接口类型:

type MyInterface interface {
    MyMethod()
}
type MyInterface1 interface {
    MyInterface
}
  • 因此,一个带有自身Method的嵌入其他接口类型的接口类型,比如:
type 03 interface {
    E1
    E2
    MyMethod03()
}

它的type set可以看成E1、E2和E3(type E3 interface { MyMethod03})的type set的交集。

3. 替换type list的新语法方案

我们再回到前面提到的新语法方案:

// type set 新语法
type SignedInteger interface {
    ~int | ~int8 | ~int16 | ~int32 | ~int64
}

Go开发团队给那些用于作为约束或被嵌入到作为约束的接口类型中的接口类型的定义做了重新描述,称这类接口类型的定义中可以嵌入一些额外的结构,被称为interface elements,其组成如下图:

  • 图中MyInterface是一个仅用于约束或嵌入到作为约束的接口类型中的类型;
  • MyInterface除了拥有自己的方法列表(M1、M2)外,还可以嵌入额外的结构:interface elements,就是T1|T2|~T3|T4…|Tn那一行,这一行即替代了原先方案中的type list;
  • interface elements这一行有三个值得关注的事情:
    • T1、T2、T4、Tn这些仅代表type set仅为自身的类型;
    • ~T3的type set 为所有underlying type为T3的类型,~T3被称为approximation elements;
    • 管道符将这些类型连接在一起,共同构成一个union element,该union element的type set为所有这些类型的type set的并集。

好了现在一切都建立在type set这个概念上。那么当上述接口类型作为类型参数的约束时,要想满足该约束,可以作为类型参数的实参,那么传入的类型应该在作为约束的接口类型的type set中。

有了前面关于type set以及接口嵌入的type set的铺垫,作为约束的接口类型的理解就容易多了。无论是单纯的接口类型还是使用嵌入其他接口组合而成的接口类型,亦或是既包括嵌入也拥有自己的method list的接口类型。

4. 问题

Ian的issue一发出就得到了社区的重点关注,并引来的激烈的讨论,但从头看到尾,似乎大家都有些“跑题”,关于这个proposal的真正疑问在于approximation elements身上:

  • 是否有必要单独拿出approximation elements这个概念

我们回顾一下当前泛型语法作为约束的接口定义所使用的type list语法,看看当前的type list语法中各个类型是否是仅代表自身?

// https://go2goplay.golang.org/p/5VbaSCQ8-Dq
package main

import (
    "fmt"
)

type S1 struct {
    Name string
    Age  int
}

type S2 S1

type MyC4 interface {
    type struct {
        Name string
        Age  int
    }, int
}

func F4[T MyC4](t T) {
    fmt.Printf("%T\n", t)
}

type MyInt int

func main() {
    var t1 = S1{"tony", 17}
    F4(t1) // main.S1
    var t2 = S2{"tony", 17}
    F4(t2) // main.S2
    var n MyInt = 3
    F4(n) // main.MyInt
}

我们看到作为约束的接口类型MyC4的type list中有两个类型:一个匿名struct和int。之后我们分别使用S1、S2和MyInt作为类型参数的实参,居然都通过了!也就是说当前的type list中的类型按照type set的概念解释,都属于approximation element,只要是underlying type在type list中,那么就可以作为类型参数的实参,通过约束检查。

那就是说:

我们是否可以只将:

type I1 interface {
    type int, string, float64
    ... ...
}

换成:

type I1 interface {
    int | string | float64
    ... ...
}

而无需~这个符号呢?

  • 如果~符号是必要的,可否不用~符号?

Go语言中没有使用~运算符,但这个符号在其他主流语言,比如C中是位运算符,而且代表的“非”这个运算符。因此将其用在类型T前面,打眼一看,以为其含义是“不是类型T的类型”。而新proposal则将其用于表示approximation element。这让很多gopher提出异议,希望换一个符号,比如T+等。但目前尚无定论。

5. 小结

能力有限,以上一些对该proposal的理解可能有误,欢迎交流指正。

type set并没有改变什么,只是完成了对interface与实现interface的重新解释。 但是对于后续将interface element用于普通interface类型定义可能有重大的意义。当前的带有interface element的interface类型仅能用于作为泛型类型参数的约束,这与普通interface之间的gap早晚要“填上”,不过这已经不是这个proposal要解决的事情。

从泛型提出到如今,我已经感到泛型的引入极大增加了复杂性 ,即便没有滥用泛型,没有耍奇技淫巧,泛型的引入也让go复杂性陡增。就像这个proposal,认真阅读并理解还是需要花费不少时间和精力的。


“Gopher部落”知识星球正式转正(从试运营星球变成了正式星球)!“gopher部落”旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,>每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需>求!部落目前虽小,但持续力很强。在2021年上半年,部落将策划两个专题系列分享,并且是部落独享哦:

  • Go技术书籍的书摘和读书体会系列
  • Go与eBPF系列

欢迎大家加入!

Go技术专栏“改善Go语⾔编程质量的50个有效实践”正在慕课网火热热销中!本专栏主要满足>广大gopher关于Go语言进阶的需求,围绕如何写出地道且高质量Go代码给出50条有效实践建议,上线后收到一致好评!欢迎大家订
阅!

img{512x368}

我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网热卖>中,欢迎小伙伴们订阅学习!

img{512x368}

我爱发短信:企业级短信平台定制开发专家 https://tonybai.com/。smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。2020年4月8日,中国三大电信运营商联合发布《5G消息白皮书》,51短信平台也会全新升级到“51商用消息平台”,全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

  • 微博:https://weibo.com/bigwhite20xx
  • 微信公众号:iamtonybai
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • “Gopher部落”知识星球:https://public.zsxq.com/groups/51284458844544

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

对Go 1.16 io/fs设计的第一感觉:得劲儿!

1. 设计io/fs的背景

Go语言的接口是Gopher最喜欢的语法元素之一,其隐式的契约满足和“当前唯一可用的泛型机制”的特质让其成为面向组合编程的强大武器,其存在为Go建立事物抽象奠定了基础,同时也是建立抽象的主要手段。

Go语言从诞生至今,最成功的接口定义之一就是io.Writer和io.Reader接口:

type Writer interface {
    Write(p []byte) (n int, err error)
}

type Reader interface {
    Read(p []byte) (n int, err error)
}

这两个接口建立了对数据源中的数据操作的良好的抽象,通过该抽象我们可以读或写满足这两个接口的任意数据源:

  • 字符串
r := strings.NewReader("hello, go")
r.Read(...)
  • 字节序列
r := bytes.NewReader([]byte("hello, go"))
r.Read(...)
  • 文件内数据
f := os.Open("foo.txt") // f 满足io.Reader
f.Read(...)
  • 网络socket
r, err :=  net.DialTCP("192.168.0.10", nil, raddr *TCPAddr) (*TCPConn, error)
r.Read(...)
  • 构造HTTP请求
req, err := http.NewRequestWithContext(ctx, "POST", url, bytes.NewReader([]byte("hello, go"))
  • 读取压缩文件内容
func main() {
    f, err := os.Open("hello.txt.gz")
    if err != nil {
        log.Fatal(err)
    }

    zr, err := gzip.NewReader(f)
    if err != nil {
        log.Fatal(err)
    }

    if _, err := io.Copy(os.Stdout, zr); err != nil {
        log.Fatal(err)
    }

    if err := zr.Close(); err != nil {
        log.Fatal(err)
    }
}

… …

能构架出io.Reader和Writer这样的抽象,与Go最初核心团队的深厚的Unix背景是密不可分的,这一抽象可能深受“在UNIX中,一切都是字节流”这一设计哲学的影响。

Unix还有一个设计哲学:一切都是文件,即在Unix中,任何有I/O的设备,无论是文件、socket、驱动等,在打开设备之后都有一个对应的文件描述符,Unix将对这些设备的操作简化在抽象的文件中了。用户只需要打开文件,将得到的文件描述符传给相应的操作函数,操作系统内核就知道如何根据这个文件描述符得到具体设备信息,内部隐藏了对各种设备进行读写的细节。

并且Unix还使用树型的结构将各种抽象的文件(数据文件、socket、磁盘驱动器、外接设备等)组织起来,通过文件路径对其进行访问,这样的一个树型结构构成了文件系统。

不过由于历史不知名的某个原因,Go语言并没有在标准库中内置对文件以及文件系统的抽象!我们知道如今的os.File是一个具体的结构体类型,而不是抽象类型:

// $GOROOT/src/os/types.go

// File represents an open file descriptor.
type File struct {
        *file // os specific
}

结构体os.File中唯一的字段file指针还是一个操作系统相关的类型,我们以os/file_unix.go为例,在unix中,file的定义如下:

// file is the real representation of *File.
// The extra level of indirection ensures that no clients of os
// can overwrite this data, which could cause the finalizer
// to close the wrong file descriptor.
type file struct {
        pfd         poll.FD
        name        string
        dirinfo     *dirInfo // nil unless directory being read
        nonblock    bool     // whether we set nonblocking mode
        stdoutOrErr bool     // whether this is stdout or stderr
        appendMode  bool     // whether file is opened for appending
}

Go语言之父Rob Pike对当初os.File没有被定义为interface而耿耿于怀

不过就像Russ Cox在上述issue中的comment那样:“我想我会认为io.File应该是接口,但现在这一切都没有意义了”:

但在Go 1.16的embed文件功能设计过程中,Go核心团队以及参与讨论的Gopher们认为引入一个对File System和File的抽象,将会像上面的io.Reader和io.Writer那样对Go代码产生很大益处,同时也会给embed功能的实现带去便利!于是Rob Pike和Russ Cox亲自上阵完成了io/fs的设计

2. 探索io/fs包

io/fs的加入也不是“临时起意”,早在很多年前的godoc实现时,对一个抽象的文件系统接口的需求就已经被提了出来并给出了实现:

最终这份实现以godoc工具的vfs包的形式一直长期存在着。虽然它的实现有些复杂,抽象程度不够,但却对io/fs包的设计有着重要的参考价值。

Go语言对文件系统与文件的抽象以io/fs中的FS接口类型和File类型落地,这两个接口的设计遵循了Go语言一贯秉持的“小接口原则”,并符合开闭设计原则(对扩展开放,对修改关闭)。

// $GOROOT/src/io/fs/fs.go
type FS interface {
        // Open opens the named file.
        //
        // When Open returns an error, it should be of type *PathError
        // with the Op field set to "open", the Path field set to name,
        // and the Err field describing the problem.
        //
        // Open should reject attempts to open names that do not satisfy
        // ValidPath(name), returning a *PathError with Err set to
        // ErrInvalid or ErrNotExist.
        Open(name string) (File, error)
}

// A File provides access to a single file.
// The File interface is the minimum implementation required of the file.
// A file may implement additional interfaces, such as
// ReadDirFile, ReaderAt, or Seeker, to provide additional or optimized functionality.
type File interface {
        Stat() (FileInfo, error)
        Read([]byte) (int, error)
        Close() error
}

FS接口代表虚拟文件系统的最小抽象,它仅包含一个Open方法;File接口则是虚拟文件的最小抽象,仅包含抽象文件所需的三个共同方法(不能再少了)。我们可以基于这两个接口通过Go常见的嵌入接口类型的方式进行扩展,就像io.ReadWriter是基于io.Reader的扩展那样。在这份设计提案中,作者还将这种方式命名为extension interface,即在一个基本接口类型的基础上,新增一到多个新方法以形成一个新接口。比如下面的基于FS接口的extension interface类型StatFS:

// A StatFS is a file system with a Stat method.
type StatFS interface {
        FS

        // Stat returns a FileInfo describing the file.
        // If there is an error, it should be of type *PathError.
        Stat(name string) (FileInfo, error)
}

对于File这个基本接口类型,fs包仅给出一个extension interface:ReadDirFile,即在File接口的基础上增加了一个ReadDir方法形成的,这种用扩展方法名+基础接口名来命名一个新接口类型的方式也是Go的惯用法。

对于FS接口,fs包给出了一些扩展FS的常见“新扩展接口”的样例:

以fs包的ReadDirFS接口为例:

// $GOROOT/src/io/fs/readdir.go
type ReadDirFS interface {
    FS

    // ReadDir reads the named directory
    // and returns a list of directory entries sorted by filename.
    ReadDir(name string) ([]DirEntry, error)
}

// ReadDir reads the named directory
// and returns a list of directory entries sorted by filename.
//
// If fs implements ReadDirFS, ReadDir calls fs.ReadDir.
// Otherwise ReadDir calls fs.Open and uses ReadDir and Close
// on the returned file.
func ReadDir(fsys FS, name string) ([]DirEntry, error) {
    if fsys, ok := fsys.(ReadDirFS); ok {
        return fsys.ReadDir(name)
    }

    file, err := fsys.Open(name)
    if err != nil {
        return nil, err
    }
    defer file.Close()

    dir, ok := file.(ReadDirFile)
    if !ok {
        return nil, &PathError{Op: "readdir", Path: name, Err: errors.New("not implemented")}
    }

    list, err := dir.ReadDir(-1)
    sort.Slice(list, func(i, j int) bool { return list[i].Name() < list[j].Name() })
    return list, err
}

我们看到伴随着ReadDirFS,标准库还提供了一个helper函数:ReadDir。该函数的第一个参数为FS接口类型的变量,在其内部实现中,ReadDir先通过类型断言判断传入的fsys是否实现了ReadDirFS,如果实现了,就直接调用其ReadDir方法;如果没有实现则给出了常规实现。其他几个FS的extension interface也都有自己的helper function,这也算是Go的一个惯例。如果你要实现你自己的FS的扩展,不要忘了这个惯例:给出伴随你的扩展接口的helper function

标准库中一些涉及虚拟文件系统的包在Go 1.16版本中做了对io/fs的适配,比如:os、net/http、html/template、text/template、archive/zip等。

以http.FileServer为例,Go 1.16版本之前建立一个静态文件Server一般这么来写:

// github.com/bigwhite/experiments/blob/master/iofs/fileserver_classic.go
package main

import "net/http"

func main() {
    http.ListenAndServe(":8080", http.FileServer(http.Dir(".")))
}

Go 1.16 http包对fs的FS和File接口做了适配后,我们可以这样写:

// github.com/bigwhite/experiments/blob/master/iofs/fileserver_iofs.go
package main

import (
    "net/http"
    "os"
)

func main() {
    http.ListenAndServe(":8080", http.FileServer(http.FS(os.DirFS("./"))))
}

os包新增的DirFS函数返回一个fs.FS的实现:一个以传入dir为根的文件树构成的File System。

我们可以参考DirFS实现一个goFilesFS,该FS的实现仅返回以.go为后缀的文件:

// github.com/bigwhite/experiments/blob/master/iofs/gofilefs/gofilefs.go

package gfs

import (
    "io/fs"
    "os"
    "strings"
)

func GoFilesFS(dir string) fs.FS {
    return goFilesFS(dir)
}

type goFile struct {
    *os.File
}

func Open(name string) (*goFile, error) {
    f, err := os.Open(name)
    if err != nil {
        return nil, err
    }
    return &goFile{f}, nil
}

func (f goFile) ReadDir(count int) ([]fs.DirEntry, error) {
    entries, err := f.File.ReadDir(count)
    if err != nil {
        return nil, err
    }
    var newEntries []fs.DirEntry

    for _, entry := range entries {
        if !entry.IsDir() {
            ss := strings.Split(entry.Name(), ".")
            if ss[len(ss)-1] != "go" {
                continue
            }
        }
        newEntries = append(newEntries, entry)
    }
    return newEntries, nil
}

type goFilesFS string

func (dir goFilesFS) Open(name string) (fs.File, error) {
    f, err := Open(string(dir) + "/" + name)
    if err != nil {
        return nil, err // nil fs.File
    }
    return f, nil
}

上述GoFilesFS的实现中:

  • goFilesFS实现了io/fs的FS接口,而其Open方法返回的fs.File实例为我自定义的goFile结构;
  • goFile结构通过嵌入*os.File满足了io/fs的File接口;
  • 我们重写goFile的ReadDir方法(覆盖os.File的同名方法),在这个方法中我们过滤掉非.go后缀的文件。

有了GoFilesFS的实现后,我们就可以将其传给http.FileServer了:

// github.com/bigwhite/experiments/blob/master/iofs/fileserver_gofilefs.go
package main

import (
    "net/http"

    gfs "github.com/bigwhite/testiofs/gofilefs"
)

func main() {
    http.ListenAndServe(":8080", http.FileServer(http.FS(gfs.GoFilesFS("./"))))
}

通过浏览器打开localhost:8080页面,我们就能看到仅由go源文件组成的文件树!

3. 使用io/fs提高代码可测性

抽象的接口意味着降低耦合,意味着代码可测试性的提升。Go 1.16增加了对文件系统和文件的抽象之后,我们以后再面对文件相关代码时,我们便可以利用io/fs提高这类代码的可测试性。

我们有这样的一个函数:

func FindGoFiles(dir string) ([]string, error)

该函数查找出dir下所有go源文件的路径并放在一个[]string中返回。我们可以很轻松的给出下面的第一版实现:

// github.com/bigwhite/experiments/blob/master/iofs/gowalk/demo1/gowalk.go

package demo

import (
    "os"
    "path/filepath"
    "strings"
)

func FindGoFiles(dir string) ([]string, error) {
    var goFiles []string
    err := filepath.Walk(dir, func(path string, info os.FileInfo, err error) error {
        if info.IsDir() {
            return nil
        }

        ss := strings.Split(path, ".")
        if ss[len(ss)-1] != "go" {
            return nil
        }

        goFiles = append(goFiles, path)
        return nil
    })
    if err != nil {
        return nil, err
    }

    return goFiles, nil
}

这一版的实现直接使用了filepath的Walk函数,它与os包是紧绑定的,即要想测试这个函数,我们需要在磁盘上真实的构造出一个文件树,就像下面这样:

$tree testdata
testdata
└── foo
    ├── 1
    │   └── 1.txt
    ├── 1.go
    ├── 2
    │   ├── 2.go
    │   └── 2.txt
    └── bar
        ├── 3
        │   └── 3.go
        └── 4.go

按照go惯例,我们将测试依赖的外部数据文件放在testdata下面。下面是针对上面函数的测试文件:

// github.com/bigwhite/experiments/blob/master/iofs/gowalk/demo1/gowalk_test.go
package demo

import (
    "testing"
)

func TestFindGoFiles(t *testing.T) {
    m := map[string]bool{
        "testdata/foo/1.go":       true,
        "testdata/foo/2/2.go":     true,
        "testdata/foo/bar/3/3.go": true,
        "testdata/foo/bar/4.go":   true,
    }

    files, err := FindGoFiles("testdata/foo")
    if err != nil {
        t.Errorf("want nil, actual %s", err)
    }

    if len(files) != 4 {
        t.Errorf("want 4, actual %d", len(files))
    }

    for _, f := range files {
        _, ok := m[f]
        if !ok {
            t.Errorf("want [%s], actual not found", f)
        }
    }
}

FindGoFiles函数的第一版设计显然可测性较差,需要对依赖特定布局的磁盘上的文件,虽然testdata也是作为源码提交到代码仓库中的。

有了io/fs包后,我们用FS接口来提升一下FindGoFiles函数的可测性,我们重新设计一下该函数:

// github.com/bigwhite/experiments/blob/master/iofs/gowalk/demo2/gowalk.go

package demo

import (
    "io/fs"
    "strings"
)

func FindGoFiles(dir string, fsys fs.FS) ([]string, error) {
    var newEntries []string
    err := fs.WalkDir(fsys, dir, func(path string, entry fs.DirEntry, err error) error {
        if entry == nil {
            return nil
        }

        if !entry.IsDir() {
            ss := strings.Split(entry.Name(), ".")
            if ss[len(ss)-1] != "go" {
                return nil
            }
            newEntries = append(newEntries, path)
        }
        return nil
    })

    if err != nil {
        return nil, err
    }

    return newEntries, nil
}

这次我们给FindGoFiles增加了一个fs.FS类型的参数fsys,这是解除掉该函数与具体FS实现的关键。当然demo1的测试方法同样适用于该版FindGoFiles函数:

// github.com/bigwhite/experiments/blob/master/iofs/gowalk/demo2/gowalk_test.go
package demo

import (
    "os"
    "testing"
)

func TestFindGoFiles(t *testing.T) {
    m := map[string]bool{
        "testdata/foo/1.go":       true,
        "testdata/foo/2/2.go":     true,
        "testdata/foo/bar/3/3.go": true,
        "testdata/foo/bar/4.go":   true,
    }

    files, err := FindGoFiles("testdata/foo", os.DirFS("."))
    if err != nil {
        t.Errorf("want nil, actual %s", err)
    }

    if len(files) != 4 {
        t.Errorf("want 4, actual %d", len(files))
    }

    for _, f := range files {
        _, ok := m[f]
        if !ok {
            t.Errorf("want [%s], actual not found", f)
        }
    }
}

但这不是我们想要的,既然我们使用了io/fs.FS接口,那么一切实现了fs.FS接口的实体均可被用来构造针对FindGoFiles的测试。但自己写一个实现了fs.FS接口以及fs.File相关接口还是比较麻烦的,Go标准库已经想到了这点,为我们提供了testing/fstest包,我们可以直接利用fstest包中实现的基于memory的FS来对FindGoFiles进行测试:

// github.com/bigwhite/experiments/blob/master/iofs/gowalk/demo3/gowalk_test.go
package demo

import (
    "testing"
    "testing/fstest"
)

/*
$tree testdata
testdata
└── foo
    ├── 1
    │   └── 1.txt
    ├── 1.go
    ├── 2
    │   ├── 2.go
    │   └── 2.txt
    └── bar
        ├── 3
        │   └── 3.go
        └── 4.go

5 directories, 6 files

*/

func TestFindGoFiles(t *testing.T) {
    m := map[string]bool{
        "testdata/foo/1.go":       true,
        "testdata/foo/2/2.go":     true,
        "testdata/foo/bar/3/3.go": true,
        "testdata/foo/bar/4.go":   true,
    }

    mfs := fstest.MapFS{
        "testdata/foo/1.go":       {Data: []byte("package foo\n")},
        "testdata/foo/1/1.txt":    {Data: []byte("1111\n")},
        "testdata/foo/2/2.txt":    {Data: []byte("2222\n")},
        "testdata/foo/2/2.go":     {Data: []byte("package bar\n")},
        "testdata/foo/bar/3/3.go": {Data: []byte("package zoo\n")},
        "testdata/foo/bar/4.go":   {Data: []byte("package zoo1\n")},
    }

    files, err := FindGoFiles("testdata/foo", mfs)
    if err != nil {
        t.Errorf("want nil, actual %s", err)
    }

    if len(files) != 4 {
        t.Errorf("want 4, actual %d", len(files))
    }

    for _, f := range files {
        _, ok := m[f]
        if !ok {
            t.Errorf("want [%s], actual not found", f)
        }
    }
}

由于FindGoFiles接受了fs.FS类型变量作为参数,使其可测性显著提高,我们可以通过代码来构造测试场景,而无需在真实物理磁盘上构造复杂多变的测试场景。

4. 小结

io/fs的加入让我们易于面向接口编程,而不是面向os.File这个具体实现。io/fs的加入丝毫没有违和感,就好像这个包以及其中的抽象在Go 1.0版本发布时就存在的一样。这也是Go interface隐式依赖的特质带来的好处,让人感觉十分得劲儿!

本文中涉及的代码可以在这里下载。https://github.com/bigwhite/experiments/tree/master/iofs


“Gopher部落”知识星球正式转正(从试运营星球变成了正式星球)!“gopher部落”旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!部落目前虽小,但持续力很强。在2021年上半年,部落将策划两个专题系列分享,并且是部落独享哦:

  • Go技术书籍的书摘和读书体会系列
  • Go与eBPF系列

欢迎大家加入!

Go技术专栏“改善Go语⾔编程质量的50个有效实践”正在慕课网火热热销中!本专栏主要满足广大gopher关于Go语言进阶的需求,围绕如何写出地道且高质量Go代码给出50条有效实践建议,上线后收到一致好评!欢迎大家订阅!

img{512x368}

我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网热卖中,欢迎小伙伴们订阅学习!

img{512x368}

我爱发短信:企业级短信平台定制开发专家 https://tonybai.com/。smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。2020年4月8日,中国三大电信运营商联合发布《5G消息白皮书》,51短信平台也会全新升级到“51商用消息平台”,全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

  • 微博:https://weibo.com/bigwhite20xx
  • 微信公众号:iamtonybai
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • “Gopher部落”知识星球:https://public.zsxq.com/groups/51284458844544

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats