Is it possible get a reflect.Type without creating the value?

100 views
Skip to first unread message

David DENG

unread,
Jun 24, 2013, 7:18:11 PM6/24/13
to golan...@googlegroups.com
I only need the type information (as a reflect.Type), but reflect.TypeOf receives a value. How can I get the reflect.Type without creating a value?

Thx!

David

Rémy Oudompheng

unread,
Jun 24, 2013, 7:21:02 PM6/24/13
to David DENG, golang-nuts


Le 25 juin 2013 01:18, "David DENG" <david...@gmail.com> a écrit :
>
> I only need the type information (as a reflect.Type), but reflect.TypeOf receives a value. How can I get the reflect.Type without creating a value?
>

You need the type information of what?

Rémy.

David DENG

unread,
Jun 24, 2013, 7:27:43 PM6/24/13
to golan...@googlegroups.com, David DENG
e.g. I have a type as follow:

type Arith int

func (a *Arith) Add(a, b int) int {
}

If I make an instance of Arith: arith := make(Arith), I can get the Type object by this:

tp := reflect.TypeOf(arith);

The problem here is, I don't need the instance arith at all, making it is just for get Type object. (sometimes such instance may be huge).

How can I do it?

I think the compiler knows where the type information is.

David

Rob Pike

unread,
Jun 24, 2013, 7:32:23 PM6/24/13
to David DENG, golan...@googlegroups.com
You need an instance to get a type.

-rob

Ross Light

unread,
Jun 24, 2013, 7:42:56 PM6/24/13
to David DENG, golang-nuts
You can get avoid the allocation by doing reflect.TypeOf((*Arith)(nil)).Elem().

Ross Light | Software Engineer | li...@google.com | 661-375-7677


--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

David DENG

unread,
Jun 24, 2013, 7:49:01 PM6/24/13
to golan...@googlegroups.com, David DENG
Can it be supported in the future? I find an ugly way to do it (http://play.golang.org/p/DpOnjaev6G)

tp := reflect.TypeOf((*Arith)(nil))

This means it is possible, but not elegant.

Any consideration in the design?

David

David DENG

unread,
Jun 24, 2013, 7:51:11 PM6/24/13
to golan...@googlegroups.com, David DENG
Yes I found it too.

But if as an exported function of a package, how can I ask the caller to do such a strange thing?

David

Ian Lance Taylor

unread,
Jun 24, 2013, 7:51:57 PM6/24/13
to David DENG, golan...@googlegroups.com
On Mon, Jun 24, 2013 at 4:49 PM, David DENG <david...@gmail.com> wrote:
> Can it be supported in the future? I find an ugly way to do it
> (http://play.golang.org/p/DpOnjaev6G)
>
> tp := reflect.TypeOf((*Arith)(nil))
>
>
> This means it is possible, but not elegant.
>
> Any consideration in the design?

Because there is no way to refer directly to a type, doing anything
else would require a change to the language syntax to add special
handling for reflect.TypeOf. That is unlikely, so really it would
mean adding typeof as a builtin function. And then we would have a
special purpose builtin only for the benefit of the reflect package,
all just to permit doing something that you can already do. I don't
think this is likely to happen.

Ian

David DENG

unread,
Jun 24, 2013, 8:30:08 PM6/24/13
to golan...@googlegroups.com, David DENG
Actually reflection has been fairly important, as it is necessary for data serialization(Gob/Json). So, IMHO, it is worthy adding this buildin, and it breaks nothing else.

reflect.TypeOf((*Arith)(nil)).Elem() looks really bad, compared with : typeof Arith

David

Brad Fitzpatrick

unread,
Jun 24, 2013, 8:33:06 PM6/24/13
to David DENG, golang-nuts
What would you remove from the language to make up for this addition?



--

Nigel Tao

unread,
Jun 24, 2013, 9:58:43 PM6/24/13
to David DENG, golang-nuts
On Tue, Jun 25, 2013 at 10:30 AM, David DENG <david...@gmail.com> wrote:
> Actually reflection has been fairly important, as it is necessary for data
> serialization(Gob/Json). So, IMHO, it is worthy adding this buildin, and it
> breaks nothing else.
>
> reflect.TypeOf((*Arith)(nil)).Elem() looks really bad, compared with :
> typeof Arith

Having typeof built into the language would require having to put the
reflect.Type type (or some equivalent) into the language
specification. reflect.Type is not a trivial interface, and refers to
other types that would transitively need to be specified:
http://golang.org/pkg/reflect/#Type.

I don't think that it's worth the cost, when you can already write
reflect.TypeOf((*Arith)(nil)).Elem() today.

David DENG

unread,
Jun 24, 2013, 10:01:16 PM6/24/13
to golan...@googlegroups.com, David DENG
What if I want to get the Type of an interface? Any trick for that?

David

Jesse McNelis

unread,
Jun 24, 2013, 10:19:52 PM6/24/13
to David DENG, golang-nuts
On Tue, Jun 25, 2013 at 12:01 PM, David DENG <david...@gmail.com> wrote:
What if I want to get the Type of an interface? Any trick for that?

The trick is the same.
reflect.TypeOf((*interface{})(nil)).Elem()
 
--
=====================
http://jessta.id.au

David DENG

unread,
Jun 24, 2013, 10:49:55 PM6/24/13
to golan...@googlegroups.com, David DENG, jes...@jessta.id.au
Ok, write the *trick* to wiki.

David
Reply all
Reply to author
Forward
0 new messages