Use of map[string]interface{} or structs instead of ...interface{} for optArgs ? about rethinkdb-go HOT 14 CLOSED

👍 The functions would be much cleaner with special type for structure options.

from rethinkdb-go.

This is something that that I talked over with @crosbymichael and something I am still not sure about. Each method has a number of advantages and disadvantages.

Maps: There is not too much difference between this method and the current method however I agree it is more readable.
Structs: I agree this is by far the most readable and has the added benefit of having the required type checked at compile time (For example Durability must be a string in your example but with maps any value could be passed and the data must be validated for every function call). One issue I think might come up is that if structs are used then the driver will have to use the reflect package to convert the struct to a map to be sent to the database which is quite a bit of overhead.

I would be interested in getting a much feedback as possible regarding this issue before making a decision.

from rethinkdb-go.

I don't think this makes any overhead here we could measure ;)
As a simple solution (to avoid reflection) each structure can implement ToMap method, which can be used as an interface internally.

from rethinkdb-go.

👍 for toMap (non exported)

from rethinkdb-go.

One advantage that the use of a list of argName, argValue has is that if you are not passing any extra parameters if needed. For example:

With pairs

t.Insert(doc)

With maps

t.Insert(doc, r.OptArgs{})

from rethinkdb-go.

func (t RqlTerm) Insert(arg interface{}, optArgs ...r.OptArg) RqlTerm {
    var optArg r.OptArg
    if len(optArgs) == 0 {
        optArg = r.OptArg{}
    } else {
        optArg = optArgs[0]
    }
    ...
}

t.Insert(doc)

Although I prefer implicit version.

from rethinkdb-go.

Usage of optArgs, as currently implemented, is not easy to understand. Why not use a map or a struct ?
+1

from rethinkdb-go.

I am leaning towards using Maps and this is something I will work on soon.

from rethinkdb-go.

Structures might resolve this more clearly.

from rethinkdb-go.

Structures are definitively a good solution from a documentation point of view...

from rethinkdb-go.

Sorry I meant to say structures :D However I will look at both.

from rethinkdb-go.

I have added a new branch named dev which I will use to work on changes that make any API changes. Currently I have worked on updating the driver to use structs instead of the key/value string pairs.

If any of you could have a look at the changes that would be great.

from rethinkdb-go.

I'll look at it. If you want me to work on something, just tell me.

2013/11/16 Daniel Cannon [email protected]

I have added a new branch named dev which I will use to work on changes
that make any API changes. Currently I have worked on updating the driver
to use structs instead of the key/value string pairs.

If any of you could have a look at the changes that would be great.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/24#issuecomment-28628007
.

Jean-François Bustarret
http://jf.bustarret.com
http://www.sangetsueur.net - Jeu de simulation

from rethinkdb-go.

Thanks I will do.

from rethinkdb-go.