标签 Package 下的文章

理解Golang语句中的求值顺序

Golang在变量声明、初始化以及赋值语句上照比C语言有了许多改进:

a) 支持在同一行声明多个变量

var a, b, c int

b) 支持在同一行初始化多个变量(不同类型也可以)

var a, b, c = 5, "hello", 3.45
a, b, c := 5, "hello", 3.45 (short variable declaration)

c) 支持在同一行对多个变量进行赋值(在声明后且不同类型也可以)

a, b, c = 5, "hello", 3.45

这种语法糖我们是笑纳的,毕竟人生苦短,少写一行是一行啊^_^。

但这种语法糖却给我们带来了一些令人困惑的问题!比如下面这个就是Rob Pike在一个talk中slide(Go Course Day2)中的一个问题:

n0, n1 = n0 + n1, n0

or:

n0, n1 = op(n0,n1), n0

n0, n1的值在上述语句执行完毕后到底为多少呢?

显然这个问题涉及到Go语言的语句求值顺序(evaluation order)。求值序在任何一门编程语言中都是比较难缠的,很多情形下,语言规范给出的答案都是“undefined(未定义)” or "not specified" or “依赖实现”,尤其是对于哪些模棱两可的写法,就如Rob Pike给出的那个问题。

我们要想搞清楚Go中的求值顺序,我们需要求助于Go language specification,Go spec与Go发行版一起发布,你可以启动一个godoc web server(godoc -http=:6060,然后访问localhost:6060/ref/spec)查看go language specification。Go language specification专门有一个小节/ref/spec#Order_of_evaluation对求值顺序做了说明。

在Go specs中,有这样三点陈述:

1、变量声明(variable declaration)中的初始化表达式(initialization expressions)的求值顺序(evaluation order)由初始化依赖(initialization dependencies)决定;但对于初始化表达式内部的操作数的求值需要按照2中的顺序:从左到右;
2、在非变量初始化语句中,对表达式、赋值语句或返回语句中的操作数进行求值时,操作数中包含的函数(function)调用、方法(method)调用和通信操作(主要针对channel)将按语法从左到右的顺序求值。
3、赋值语句求值分为两个阶段,第一阶段是等号左边的index expressions、pointer indirections和等号右边的表达式中的操作数的求值顺序按照2中从左到右的顺序;第二阶段按从左到右的顺序对变量赋值。

下面我们就分别理解一下这三点。

一、变量声明中初始化表达式的求值顺序

带初始化表达式的变量声明的形式如下:

var a, b, c = expr1, expr2, expr3 //包级别或函数/方法内部

or 

a, b, c := expr1, expr2, expr3 //仅函数/方法内部

根据lang specs说明,求值顺序是由初始化依赖(initialization dependencies)规则决定的。那初始化依赖规则是什么呢?在Golang specs中也有专门章节说明:ref/spec#Package_initialization。

初始化依赖规则总结一下,大致有如下几条:

1、包中,包级别变量的初始化顺序按照声明先后的顺序,但如果某个变量(比如a)的初始化表达式中依赖其他变量(比如b),那么变量a的初始化顺序在变量b后面。
2、对于未初始化的,且不含有对应初始化表达式或其初始化表达式不依赖任何未初始化变量的变量,我们称之为"ready for initialization"变量。初始化就是按照声明顺序重复执行对下一个变量的初始化过程,直到没有"ready for initialization"变量为止。
3、如果初始化过程完毕后依然有变量处于未初始化状态,那程序有语法错误。
4、多个处于不同文件中的变量的声明顺序依赖编译器处理文件的顺序,先处理的文件中的变量的声明顺序先于后处理的文件中的所有变量。
5、依赖分析以包为单位执行,只有位于同一个包中的被依赖的变量、函数、方法才会被考虑。

规则是抽象难懂的,例子更直观易理解,我们看一个golang spec中的例子,并使用上述规则进行分析。实验环境:go 1.5, amd64,Darwin Kernel Version 13.1.0

//golang-statements-evaluating-order/example1.go
package main

import "fmt"

var (
    a = c + b
    b = f()
    c = f()
    d = 3
)

func f() int {
    d++
    return d
}

func main() {
    fmt.Println(a, b, c, d)
}

我们来分析一下程序执行后的a, b, c, d四个变量的结果值,不过不同的初始化顺序会导致结果值不同,因此分析四个变量的初始化顺序是至关重要的。

变量a, b, c, d的初始化过程如下:

1、根据规则,初始化按照变量声明先后顺序进行,因此先来分析变量a,a初始化表达式依赖b 和c;因此变量a的初始化次序排在b、c的后面;
2、按照a的初始化右值表达式,c、b在右值表达式中的出现顺序是c先于b;
3、c是否是一个ready for initialization变量呢?我们看到c依赖f这个函数,而f这个函数则依赖变量d的初始化,因此d排在c之前;
4、我们来看变量d,"d = 3",d未初始化且不含有初始化表达式,因此d是一个ready for initialization变量,我们可以从d开始初始化了。至此四个变量的初始化顺序排定 d -> c -> b -> a;(这块儿与spec中分析有差异,但从运行结果来看,应该是这个顺序;关于这个spec的issue参见#12369)
5、d初始化为3,此时已初始化变量集合[d=3];
6、接着初始化c:c = f(),因此c = 4(此时d=4),此时已初始化变量集合[c=4,d=4];
7、接下来轮到b:b = f(),因此b = 5 (此时d = 5),此时已初始化变量集合[b=5,c=4,d=5];
8、最后初始化a: a = c + b,在已初始化变量集合中我们可以找到b和c,因此a= 9,这样四个变量到此均已初始化;
9、经过分析:程序执行的结果应该是9,5,4,5。

我们来执行一下这个程序,验证一下我们的分析结果是否正确:

$go run example1.go
9 5 4 5

我们再来看一个例子,也是golang specs中的例子,我们稍作改造,并把它设定为example2:

//golang-statements-evaluating-order/example2.go
package main

import "fmt"

var a, b, c = f() + v(), g(), sqr(u()) + v()

func f() int {
    fmt.Println("calling f")
    return c
}

func g() int {
    fmt.Println("calling g")
    return a
}

func sqr(x int) int {
    fmt.Println("calling sqr")
    return x * x
}

func v() int {
    fmt.Println("calling v")
    return 1
}

func u() int {
    fmt.Println("calling u")
    return 2
}

func main() {
    fmt.Println(a, b, c)
}

同样根据变量初始化依赖规则对这个例子进行分析:

1、按照变量声明顺序,先初始化a:a= f() + v(),f()依赖变量c;v不依赖任何变量,因此变量c的初始化顺序应该在a变量前:c -> a。
2、分析c:c = sqr(u()) + v();u、sqr、v三个函数不依赖任何变量,因此c处于ready for initialization,于是对c进行初始化,函数执行顺序(从左到右)为:u() -> sqr() -> v(); 此时已初始化变量集合:[c = 5];
3、回到a:a = f() + v(),c初始化后,a也处理ready for initialization,于是对a初始化,函数执行顺序为:f() -> v(),此时已初始化变量集合:[c=5, a= 6];
4、按照变量声明次序,接下来轮到变量b:b= g(),而g()依赖a,a已经初始化完毕了,因此b也是ready for initialization,于是对b初始化,函数执行次序为:g(),至此已初始化变量集合:[c=5, a=6, b=6]。
5、经过分析:程序执行的结果应该是6,6,5。

我们来执行一下这个程序,验证一下我们的分析结果是否正确:

$go run example2.go
calling u
calling sqr
calling v
calling f
calling v
calling g
6 6 5

二、非变量初始化语句中的求值顺序

前面提到过:在非变量初始化语句中,对表达式、赋值语句或返回语句中的操作数进行求值时,操作数中包含的函数(function)调用、方法(method)调用和通信操作(主要针对channel)将按语法从左到右的顺序求值

我们同样来看一个例子:example3.go

//golang-statements-evaluating-order/example3.go
package main

import "fmt"

func f() int {
    fmt.Println("calling f")
    return 1
}

func g(a, b, c int) int {
    fmt.Println("calling g")
    return 2
}

func h() int {
    fmt.Println("calling h")
    return 3
}

func i() int {
    fmt.Println("calling i")
    return 1
}

func j() int {
    fmt.Println("calling j")
    return 1
}

func k() bool {
    fmt.Println("calling k")
    return true
}

func main() {
    var y = []int{11, 12, 13}
    var x = []int{21, 22, 23}

    var c chan int = make(chan int)
    go func() {
        c <- 1
    }()

    y[f()], _ = g(h(), i()+x[j()], <-c), k()

    fmt.Println(y)
}

y[f()], _ = g(h(), i()+x[j()], <-c), k() 这行语句是赋值语句,但赋值语句的操作数中包含函数调用、channel操作,按照规则,这些函数调用、channel操作按从左到右顺序估值。

1、按照从左到右顺序,第一个是y[f()]中的f();
2、接下来是g(),g()的参数列表依然是一个赋值操作,因此其涉及到的函数调用顺序为h(), i(),j(),<-c,因此实际上的顺序为h() –> i()–> j() –> c操作 -> g();
3、最后是k(),因此完整的调用顺序是:f()->
h() –> i()–> j() –> c操作 -> g() –> k()。

实际运行情况如下:

$go run example3.go
calling f
calling h
calling i
calling j
calling g
calling k
[11 2 13]

三、赋值语句的求值顺序

我们再回到前面Rob Pike那个问题:

n0, n1 = n0 + n1, n0

or:

n0, n1 = op(n0, n1), n0

这是一个赋值语句,根据规则3,我们对等号两端的表达式的操作数采用从左到右的求值顺序。

我们假定初值:
n0, n1 = 1, 2

1、第一阶段:等号两端表达式求值,上述问题中,只有右端有n0+n1和n0两个表达式,但表达式的操作数(n0,n1)都是初始化过后的了,因此直接将值带入,得到求值结果。求值后,语句可以看成:n0, n1 = 3, 1;
2、第二阶段:赋值。n0 =3, n1 = 1

//golang-statements-evaluating-order/example4.go
package main

import "fmt"

func example1() {
    n0, n1 := 1, 2
    n0, n1 = n0+n1, n0
    fmt.Println(n0, n1)
}

func op(a, b int) int {
    return a + b
}

func example2() {
    n0, n1 := 1, 2
    n0, n1 = op(n0, n1), n0
    fmt.Println(n0, n1)
}

func main() {
    example1()
    example2()
}

$go run example4.go
3 1
3 1

四、小结

虽说理解了规则,但实际工作中我们还是尽量不要写出像:"var a, b, c = f() + v(), g(), sqr(u()) + v()"这样复杂、难以让人理解的语句。必要的话,拆分成多行就好了,还可以增加些代码量(如果你的公司是以代码量为评价绩效指标之一的),得饶人处且饶人啊,烧脑的语句还是尽量避免为好。

以上实验代码在这里可以下载到。

五、参考资料

The Go Programming Language Specification (Version of August 5, 2015) 

理解Go 1.5 vendor

Go 1.5中(目前最新版本go1.5beta3)加入了一个experimental feature: vendor/。这个feature不是Go 1.5的正式功能,但却是Go Authors们在解决Go被外界诟病的包依赖管理的道路上的一次重要尝试。目前关于Go vendor机制的资料有限,主要的包括如下几个:

1、Russ Cox在Golang-dev group上的一个名 为"proposal: external packages" topic上的reply。
2、Go 1.5beta版发布后Russ Cox根据上面topic整理的一个doc
3、medium.com上一篇名为“Go 1.5 vendor/ experiment"的文章。

但由于Go 1.5稳定版还未发布(最新消息是2015.8月中旬发布),因此估计真正采用vendor的repo尚没有。但既然是Go官方解决方案,后续从 expreimental变成official的可能性就很大(Russ的初步计划:如果试验顺利,1.6版本默认 GO15VENDOREXPERIMENT="1";1.7中将去掉GO15VENDOREXPERIMENT环境变量)。因此对于Gophers们,搞 清楚vendor还是很必要的。本文就和大家一起来理解下vendor这个新feature。

一、vendor由来

Go第三方包依赖和管理的问题由来已久,民间知名的解决方案就有godepgb等。这次Go team在推出vendor前已经在Golang-dev group上做了长时间的调研,最终Russ Cox在Keith Rarick的proposal的基础上做了改良,形成了Go 1.5中的vendor。

Russ Cox基于前期调研的结果,给出了vendor机制的群众意见基础:
    – 不rewrite gopath
    – go tool来解决
    – go get兼容
    – 可reproduce building process

并给出了vendor机制的"4行"诠释:

If there is a source directory d/vendor, then, when compiling a source file within the subtree rooted at d, import "p" is interpreted as import "d/vendor/p" if that exists.

When there are multiple possible resolutions,the most specific (longest) path wins.

The short form must always be used: no import path can  contain “/vendor/” explicitly.

Import comments are ignored in vendored packages.

这四行诠释在group中引起了强烈的讨论,短小精悍的背后是理解上的不小差异。我们下面逐一举例理解。

二、vendor基本样例

Russ Cox诠释中的第一条是vendor机制的基础。粗犷的理解就是如果有如下这样的目录结构:

d/
   vendor/
          p/
           p.go
   mypkg/
          main.go

如果mypkg/main.go中有"import p",那么这个p就会被go工具解析为"d/vendor/p",而不是$GOPATH/src/p。

现在我们就来复现这个例子,我们在go15-vendor-examples/src/basic下建立如上目录结构(其中go15-vendor-examples为GOPATH路径):

$ls -R
d/

./d:
mypkg/    vendor/

./d/mypkg:
main.go

./d/vendor:
p/

./d/vendor/p:
p.go

其中main.go代码如下:

//main.go
package main

import "p"

func main() {
    p.P()
}

p.go代码如下:

//p.go
package p

import "fmt"

func P() {
    fmt.Println("P in d/vendor/p")
}

在未开启vendor时,我们编译d/mypkg/main.go会得到如下错误结果:

$ go build main.go
main.go:3:8: cannot find package "p" in any of:
    /Users/tony/.bin/go15beta3/src/p (from $GOROOT)
    /Users/tony/OpenSource/github.com/experiments/go15-vendor-examples/src/p (from $GOPATH)

错误原因很显然:go编译器无法找到package p,d/vendor下的p此时无效。

这时开启vendor:export GO15VENDOREXPERIMENT=1,我们再来编译执行一次:
$go run main.go
P in d/vendor/p

开启了vendor机制的go tool在d/vendor下找到了package p。

也就是说拥有了vendor后,你的project依赖的第三方包统统放在vendor/下就好了。这样go get时会将第三方包同时download下来,使得你的project无论被下载到那里都可以无需依赖目标环境而编译通过(reproduce the building process)。

三、嵌套vendor

那么问题来了!如果vendor中的第三方包中也包含了vendor目录,go tool是如何choose第三方包的呢?我们来看看下面目录结构(go15-vendor-examples/src/embeded):

d/
   vendor/
          p/
            p.go
          q/
            q.go
            vendor/
               p/
                 p.go
   mypkg/
          main.go

embeded目录下出现了嵌套vendor结构:main.go依赖的q包本身还有一个vendor目录,该vendor目录下有一个p包,这样我们就有了两个p包。到底go工具会选择哪个p包呢?显然为了验证一些结论,我们源文件也要变化一下:

d/vendor/p/p.go的代码不变。

//d/vendor/q/q.go
package q

import (
    "fmt"
    "p"
)

func Q() {
    fmt.Println("Q in d/vendor/q")
    p.P()
}

//d/vendor/q/vendor/p/p.go
package p

import "fmt"

func P() {
    fmt.Println("P in d/vendor/q/vendor/p")
}

//mypkg/main.go
package main

import (
    "p"
    "q"
)

func main() {
    p.P()
    fmt.Println("")
    q.Q()
}

目录和代码编排完毕,我们就来到了见证奇迹的时刻了!我们执行一下main.go:

$go run main.go
P in d/vendor/p

Q in d/vendor/q
P in d/vendor/q/vendor/p

可以看出main.go中最终引用的是d/vendor/p,而q.Q()中调用的p.P()则是d/vendor/q/vendor/p包的实现。go tool到底是如何在嵌套vendor情况下选择包的呢?我们回到Russ Cox关于vendor诠释内容的第二条:

   When there are multiple possible resolutions,the most specific (longest) path wins.

这句话很简略,但却引来的巨大争论。"longest path wins"让人迷惑不解。如果仅仅从字面含义来看,上面main.go的执行结果更应该是:

P in d/vendor/q/vendor/p

Q in d/vendor/q
P in d/vendor/q/vendor/p

d/vendor/q/vendor/p可比d/vendor/p路径更long,但go tool显然并未这么做。它到底是怎么做的呢?talk is cheap, show you the code。我们粗略翻看一下go tool的实现代码:

在$GOROOT/src/cmd/go/pkg.go中有一个方法vendoredImportPath,这个方法在go tool中广泛被使用

// vendoredImportPath returns the expansion of path when it appears in parent.
// If parent is x/y/z, then path might expand to x/y/z/vendor/path, x/y/vendor/path,
// x/vendor/path, vendor/path, or else stay x/y/z if none of those exist.
// vendoredImportPath returns the expanded path or, if no expansion is found, the original.
// If no expansion is found, vendoredImportPath also returns a list of vendor directories
// it searched along the way, to help prepare a useful error message should path turn
// out not to exist.
func vendoredImportPath(parent *Package, path string) (found string, searched []string)

这个方法的doc讲述的很清楚,这个方法返回所有可能的vendor path,以parentpath为x/y/z为例:

x/y/z作为parentpath输入后,返回的vendorpath包括:
   
x/y/z/vendor/path
x/y/vendor/path
x/vendor/path
vendor/path

这么说还不是很直观,我们结合我们的embeded vendor的例子来说明一下,为什么结果是像上面那样!go tool是如何resolve p包的!我们模仿go tool对main.go代码进行编译(此时vendor已经开启)。

根据go程序的package init顺序,go tool首先编译p包。如何找到p包呢?此时的编译对象是d/mypkg/main.go,于是乎parent = d/mypkg,经过vendordImportPath处理,可能的vendor路径为:

d/mypkg/vendor
d/vendor

但只有d/vendor/下存在p包,于是go tool将p包resolve为d/vendor/p,于是下面的p.P()就会输出:
P in d/vendor/p

接下来初始化q包。与p类似,go tool对main.go代码进行编译,此时的编译对象是d/mypkg/main.go,于是乎parent = d/mypkg,经过vendordImportPath处理,可能的vendor路径为:

d/mypkg/vendor
d/vendor

但只有d/vendor/下存在q包,于是乎go tool将q包resolve为d/vendor/q,由于q包自身还依赖p包,于是go tool继续对q中依赖的p包进行选择,此时go tool的编译对象变为了d/vendor/q/q.go,parent = d/vendor/q,于是经过vendordImportPath处理,可能的vendor路径为:

d/vendor/q/vendor
d/vendor/vendor
d/vendor

存在p包的路径包括:

d/vendor/q/vendor/p
d/vendor/p

此时按照Russ Cox的诠释2:choose longest,于是go tool选择了d/vendor/q/vendor/p,于是q.Q()中的p.P()输出的内容就是:
"
P in d/vendor/q/vendor/p"

如果目录结构足够复杂,这个resolve过程也是蛮繁琐的,但按照这个思路依然是可以分析出正确的包的。

另外vendoredImportPath传入的parent x/y/z并不是一个绝对路径,而是一个相对于$GOPATH/src的路径。

BTW,上述测试样例代码在这里可以下载到。

四、第三和第四条

最难理解的第二条已经pass了,剩下两条就比较好理解了。

The short form must always be used: no import path can  contain “/vendor/” explicitly.

这条就是说,你在源码中不用理会vendor这个路径的存在,该怎么import包就怎么import,不要出现import "d/vendor/p"的情况。vendor是由go tool隐式处理的。

Import comments are ignored in vendored packages.

go 1.4引入了canonical imports机制,如:

package pdf // import "rsc.io/pdf"

如果你引用的pdf不是来自rsc.io/pdf,那么编译器会报错。但由于vendor机制的存在,go tool不会校验vendor中package的import path是否与canonical import路径是否一致了。

五、问题

根据小节三中的分析,对于vendor中包的resolving过程类似是一个recursive(递归)过程。

main.go中的p使用d/vendor/p;而q.go中的p使用的是d/vendor/q/vendor/p,这样就会存在一个问题:一个工程中存 在着两个版本的p包,这也许不会带来问题,也许也会是问题的根源,但目前来看从go tool的视角来看似乎没有更好的办法。Russ Cox期望大家良好设计工程布局,作为lib的包不携带vendor更佳。

这样一个project内的所有vendor都集中在顶层vendor里面。就像下面这样:

d/
    vendor/   
            q/
            p/
            … …
    mypkg1
            main.go
    mypkg2
            main.go
    … …

另外Go vendor不支持第三方包的版本管理,没有类似godep的Godeps.json这样的存储包元信息的文件。不过目前已经有第三方的vendor specs放在了github上,之前Go team的Brad Fizpatrick也在Golang-dev上征集过类似的方案,不知未来vendor是否会支持。

六、vendor vs. internal

在golang-dev有人提到:有了vendor,internal似乎没用了。这显然是混淆了internal和vendor所要解决的问题。

internal故名思议:内部包,不是对所有源文件都可见的。vendor是存储和管理外部依赖包,更类似于external,里面的包都是copy自 外部的,工程内所有源文件均可import vendor中的包。另外internal在1.4版本中已经加入到go核心,是不可能轻易去除的,虽然到目前为止我们还没能亲自体会到internal 包的作用。

在《Go 1.5中值得关注的几个变化》一文中我提到过go 1.5 beta1似乎“不支持”internal,beta3发布后,我又试了试看beta3是否支持internal包。

结果是beta3中,build依旧不报错。但go list -json会提示错误:
"DepsErrors": [
        {
            "ImportStack": [
                "otherpkg",
                "mypkg/internal/foo"
            ],
            "Pos": "",
            "Err": "use of internal package not allowed"
        }
    ]

难道真的要到最终go 1.5版本才会让internal包发挥作用?

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! 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