proposal: reflect: add GetTypeByName function

[niubaoshu]

proposal: add a func GetTypeByName(name string)(reflect.Type,error) in reflect package。
这是有必要的。请认真考虑。

call _,typ := GetTypeByName("os.File")
fmt.Println(typ,typ.Kind) // os.File ,struct

[odeke-em]

@niubaoshu thank you for the proposal. However, would you mind giving more background to:

• the problem that you are facing
• the motivation to add this function (where you need it)
• other folks you think that might need it
• perhaps some alternatives too?

We try to carefully and pragmatically figure out what we should be added to the standard library, as APIs in here once added are forever as per the Go1.X compatibility promise, and also if something can be implemented without adding it as an official API.

[bcmills]

GetTypeByName("os.File")

What happens if there are two packages named os? (You'd presumably need to index the types by import path, not by package name.)

But I second @odeke-em's questions: what problem are you trying to solve with this?

[niubaoshu]

我在写一个序列化的程序，我需要序列化各种类型的值然后发送到服务端，服务端需要反序列化成一个对象。
client

type a interface{
...
}

func newObj()a{
....
}

var obj a
obj= newObj()
bytes:=encode(obj)
sock.Write(bytes)

server

var buf []byte
sock.Read(buf)
var obj a 

decode(buf,&a)

我需要知道obj的具体的reflect.Type,才可以实现decode函数。
当然我可以在服务器端提供registerType(t interface) 函数来注册具体的类型。
但这可能形成层层注册的现象。比如

package gob
func RegisterType(t interface) {...}

package rpc
import gob
func RegisterType(t interface) {
   gob.registerType(t)
...
}

package go-micro
import rpc

func RegisterType(t interface) {
   gob.registerType(t)
...
}

package xxx
improt go-micro

func RegisterType(t interface) {
    go-micro.registerType(t)
...
}

使用xxx包的人根本就不知道为什么要注册类型。

如果我们可以用一个string类型的字符串就可以创造出各种类型，这将带来很多的可能性。可以说是一生万物了。
这个函数将增加语言的动态性，对依赖注入也很有帮助。

写的不好，请见谅。

[bcmills]

当然我可以在服务器端提供registerType(t interface) 函数来注册具体的类型。

Lookup by name is a problem anyway. What happens if the same package is vendored into the binary under two different import paths? Then the serialization package will not know which one to use.

We have used registration in a couple of different packages (such as proto and gob), but in general it seems better to design the serialization package not to require it.

(See also golang/protobuf#268.)

[crawshaw]

This proposal conflicts with an important design goal of the reflect package: it is impossible to dynamically lookup a top-level package symbol.

This allows the linker to aggressively remove dead code, making binaries smaller. Otherwise, when you import a package, all of the code in that package would have to be included in the final binary, because the linker does not know what will be requested at run time.

I'm going to close this issue because I don't see a way the proposal can be reworked to be compatible with dead code elimination. If I'm wrong we can reopen it.