[go-nuts] How to reduce repetition in code

But you are: if you give User{} to your Read as result, then it does as you wish.
(Or maybe an &User{} and remove that & in Scan).

The problem I am having is that the datastore code takes the type of the
parameter 'result' (interface{}) and then doesn't know how to handle the
call
to q.Next. If it has a value to use of the correct type (User), then it
knows
which fields to pull back.

More generally than usage with datastore, is it possible to create a
variable
inside the function with the type passed into the interface parameter.

You could do something like this, passing in a function that
is used to create the new receiving values:

func Read(c appengine.Context, query *datastore.Query, newResult
func() interface{}) ([]interface{}, error) {
     q := query.Run(c)
     for {
         result := newResult()
         _, err := q.Next(result)
         if err == datastore.Done {
             break
         }
         if err != nil {
             return nil, err
         }
         results = append(results, result)
     }
     return results, nil
}


Alternatively, you could use reflection, which will probably
be less efficient, but the client code may look a little prettier.

// Read appends all the results of the given query to the
// results value (which must be a slice) and returns the
// resulting slice.
func Read(c appengine.Context, query *datastore.Query, results
interface{}) (interface{}, error) {
     resultsv := reflect.ValueOf(results)
     q := query.Run(c)

     elem := reflect.New(resultsv.Type().Elem())
     for i := resultsv.Len(); ; i++ {
         _, err := q.Next(elem.Interface())
         if err == datastore.Done {
             break
         }
         if err != nil {
             return nil, err
         }
         resultsv = reflect.Append(resultsv, elem.Elem())
     }
     return resultsv.Interface(), nil
}

Beware, I haven't tested or even compiled any of the above code.
Another possibility might be to send the results on a channel
or make a callback - that way you could lose the dynamic type
coercion in client code, though at some efficiency cost.

   cheers,
    rog.

Are you planning to have a fixed number of types (stored in the datastore)
that you Next method can iterate over ?

if yes, instead of using User as in your ReadUser, I would define something
such as :

type GlobalItem struct{
    Usertype *User
    Objecttype *Object
    Whatevertype *Whatever
}

to Read over.

Maybe you can even use a struct tag or define a field of type string to
make sure of the type of each GlobalItem you create.

But if you extend the number of types in your datastore, this solution
won't work anymore.