code review 3608041: reflect: add ArrayType.Slice, ArrayValue.Slice

reflect: add ArrayType.Slice, ArrayValue.Slice

Right now it's not possible to use the data within a
reflect.ArrayValue as an array without copying element by
element individually out of the array, or knowing the array
type and dimension in advance, which defeats the purpose of
reflection.

This changeset solves that problem by:

a) Modifying the compiler to dump the slice type next to the
   array type itself, adding an extra element to
   {reflect,runtime}.ArrayType

b) Introducing the Slice() method on ArrayType, giving access
   to its respective SliceType (analog to Elem()).

c) Introducing Slice(beg, end) method on ArrayValue, giving
   access to a dynamic SliceValue (analog to SliceValue's
   Slice method).

d) Adding the extra Slice(beg, end) SliceValue method into the
   ArrayOrSliceValue interface, since both of them are able to
   handle it correctly.

[niemeyer, 2010-12-12 22:02:12]

Hello r, rsc (cc: golang-dev@googlegroups.com),

I'd like you to review this change.

[nigeltao_gnome, 2010-12-12 22:41:11]

Rob and Russ are more qualified to make a technical review of this change.

I just wanted to point out that our change description style should
start with a one-line summary of the change, prefixed by the primary
affected package (or e.g. "doc" for documentation changes). This makes
it easier to scan changelist summaries in a mail reader, and to
prepare the release notes for the weekly releases.

For example, this change could start with: "reflect: add Slice methods
to Array{Type,Value}."

[niemeyer, 2010-12-12 23:14:27]

> I just wanted to point out that our change description style should
> start with a one-line summary of the change, prefixed by the primary

Will keep that in mind, thanks.

[rsc, 2010-12-13 02:42:22]

The short summary as I understand it is

reflect: add ArrayType.Slice, ArrayValue.Slice

I'm not sure what I think of this.  You claimed that
it's impossible to use the data inside a reflect.ArrayValue
without knowing the size and type of the array, but
that's definitely false.  You can use the data via the
reflection interface; the same is true of structs, maps,
and any other type.

Adding Slice means that you can then use Interface()
to get an interface value with the slice, so if you know
the type but not the size then you can get back to a
non-reflected Go value.  But how often does that happen?

I'm also a bit concerned about starting to add cross-links
between related types, like Array -> Slice.  Where does
it stop?  Here they are very clearly related, but what will
be the next one?

Another potentially useful cross-link would be T -> *T
but that adds a whole host of other issues to the reflection
interface, like when it's okay to call Addr() and when not.

I am leaning toward leaving this out of the current reflect
but treating this CL as something to keep in mind when
we do the next redesign of reflect (the redesign should also
address the T -> *T question, among others).

What is the use case you have where this Array -> Slice
functionality is important now?

Russ

[r, 2010-12-13 05:17:20]

you managed to put in words what's been subconsciously bothering me.
the analogy with T and *T came to me too but i didn't know which way
to take it.  "later" does seem like a reasonable resolution for now.

-rob

[niemeyer, 2010-12-13 12:35:13]

Hi Russ,

> I'm not sure what I think of this.  You claimed that
> it's impossible to use the data inside a reflect.ArrayValue
> without knowing the size and type of the array, but
> that's definitely false.  You can use the data via the
> reflection interface; the same is true of structs, maps,
> and any other type.

I claimed it is impossible without knowing the array size
*or* iterating element by element individually, which is
what you suggest above.

> Adding Slice means that you can then use Interface()
> to get an interface value with the slice, so if you know
> the type but not the size then you can get back to a
> non-reflected Go value.  But how often does that happen?

My use case is this: I'm writing a serialization package,
and would like to support structures similar to the
following:

    type UnknownType struct {
        v [N]byte
    }

This can't be done through reflection today without iterating
element by element the byte array, which feels like a very
costly operation for what is going on.  Extracting a []byte
(or []int32, etc) type out of this would solve the issue in
an elegant way.

> I'm also a bit concerned about starting to add cross-links
> between related types, like Array -> Slice.  Where does
> it stop?  Here they are very clearly related, but what will
> be the next one?
> 
> Another potentially useful cross-link would be T -> *T
> but that adds a whole host of other issues to the reflection
> interface, like when it's okay to call Addr() and when not.

It does sound like a useful feature as well, to be honest, and
one I won't be surprised if someone comes up with a compelling
use case for, but I don't have one.

> I am leaning toward leaving this out of the current reflect
> but treating this CL as something to keep in mind when
> we do the next redesign of reflect (the redesign should also
> address the T -> *T question, among others).

That sounds reasonable to me.  Right now I'm forbidding dumping
arrays entirely and forcing the use of slices.  If that bothers
me too much in real use, I can play unsafe games to grab the
underlying memory.

My main motivation with this CL *right now* was indeed to explain
a real problem which exists with reflection today, and bring up
that this approach is feasible and clean.  I failed to do
that without code, in the mailing list.

> What is the use case you have where this Array -> Slice
> functionality is important now?

I hope this makes the problem clearer.

[niemeyer, 2010-12-13 12:36:34]

(updated the short summary)

[rsc, 2011-01-19 19:43:53]

removing reviewers.  
created http://code.google.com/p/go/issues/detail?id=1432