Arrays vs slices for things like UUIDs
Albert Strasheim
I've been working on a UUID package. I would like to get your opinions
on whether one wants to use slices or arrays for this kind of thing.
Basically, one would either have:
type Uuid []byte
or
type Uuid [16]byte
and then either
func NewV4() Uuid
or
func NewV4() *Uuid
I like the array one because it gives an explicit size. This
eliminates strange things like when someone writes
var uuid Uuid
and ends with a zero-length UUID which then causes things like the
String function to fail with an index out of range error later on in
the code.
On the other hand, the array version causes you to write things like:
_, err := rand.Read(uuid[0:])
and
copy(dstuuid[0:], srcuuid[0:])
which are a bit strange. There also seems to be a bit of overhead in
creating these slices around the array.
Finally, if you have a function like this:
func Parse(str string) (Uuid, os.Error)
with slices you can just return (nil, err), but with arrays you need
to actually return a UUID full of zeros. Or you need to return *Uuid.
Finally, Effective Go's Array section seems to indicate that using a
slice is the idiomatic Go way. So maybe that's the final word.
Thoughts?
Regards
Albert
Eric Clark
> _, err := rand.Read(uuid[0:])
>
I recently wrote a par2 verifier and that format has a lot of fixed
size arrays. My first pass was to use arrays but I quickly became
tired this style that I quoted from your post. I had to slice them to
do almost anything. The second day working on it I went back and
changed them all to arrays because of it.
Just my 2 cents.
Eric
Nigel Tao
> On the other hand, the array version causes you to write things like:
> _, err := rand.Read(uuid[0:])
You can drop the 0. uuid[:] works fine.
roger peppe
> Hello all
>
> I've been working on a UUID package. I would like to get your opinions
> on whether one wants to use slices or arrays for this kind of thing.
>
> Basically, one would either have:
>
> type Uuid []byte
>
> or
>
> type Uuid [16]byte
>
> and then either
>
> func NewV4() Uuid
>
> or
>
> func NewV4() *Uuid
>
> I like the array one because it gives an explicit size. This
> eliminates strange things like when someone writes
>
> var uuid Uuid
>
> and ends with a zero-length UUID which then causes things like the
> String function to fail with an index out of range error later on in
> the code.
>
> On the other hand, the array version causes you to write things like:
>
> _, err := rand.Read(uuid[0:])
>
> and
>
> copy(dstuuid[0:], srcuuid[0:])
you could just use dstuuid = srcuuid here.
> which are a bit strange. There also seems to be a bit of overhead in
> creating these slices around the array.
>
> Finally, if you have a function like this:
>
> func Parse(str string) (Uuid, os.Error)
>
> with slices you can just return (nil, err), but with arrays you need
> to actually return a UUID full of zeros. Or you need to return *Uuid.
>
> Finally, Effective Go's Array section seems to indicate that using a
> slice is the idiomatic Go way. So maybe that's the final word.
>
> Thoughts?
>
> Regards
>
> Albert
if you're using a lot of UUIDs, then the array representation
will be more efficient as it needs no allocation. this
kind of use is, i believe, one of the motivating features
for having arrays in the Go language.
I think you're making it harder work than you need to though.
The only place that you actually needed a slice above was
in the Read example.
To copy a Uuid:
srcuuid = dstuuid
To return an empty uuid and an error:
return Uuid{}, os.ErrorString(...)
there will be some overhead if you take a slice of a uuid
that's a local variable, because it takes its address which
causes the uuid to be heap-allocated. whether this is
significant or not will depend on your program.