search

dtromb / gogsl

A (nearly) complete binding of the GNU Scientific Library for Go
GNU General Public License v2.0
13 stars 2 forks source link

gogsl stuttering #3

Open sbinet opened 9 years ago

sbinet commented 9 years ago

gogsl is nice, feature-wise, but a bit long in the mouth:

gogsl.GslError, gogsl.GslErrorHandler, gogsl.GslReference, gogsl/bspline.GslBsplineWorkspace, gogsl/vector.GslVectorFloat, ...

I'd propose to remove all the redundant Gsl bits: gsl.Error, gsl.ErrorHandler, gsl.Reference, gsl/bspline.Workspace, gsl/vector.VectorFloat

and rename github.com/dtromb/gogsl into github.com/dtromb/gsl (or /go-gsl)

that's more go idiomatic.

dtromb commented 9 years ago

The code is generated - the symbols are named the way they are by camel-casing the C symbol names at underscores. So, there's obviously a tradeoff here between symbols being named in a go-like way, and preserving the ability to easily/unambiguously find the symbol corresponding to a given C symbol.

I'll leave this open and we can review possibilities for changing the name mappings when the packages are all implemented - you're correct that some of them are a little long to type - but when I tried shortening them, there were collisions in addition to the above concern (there are literally thousands of symbols...)

sbinet commented 9 years ago

right. the gogsl -> gsl is easy though (and, admittedly, when you write go code, you know that's go :))

I had a branch implementing most of these renaming bikesheds (which I would need to rebase) but I'll keep quiet on this issue for now and speak up when the packages are all implemented. (do ping this issue, though.)

dtromb commented 9 years ago

Ok, now that I've completed a first-pass through getting all of the functionality in GSL in place and usable, and therefore finished making this problem worse - it's a great time to circle back and fix it.

If you want to rebase and have a swing at it, that would be tremendous. Or we could try to come up with some guidelines for name mappings here.

The way things currently work: the "basic transform" is that the C names are camel-cased at underscores. Then, any shortening transformations are applied. For the generated code's function symbols, the third parameter of the #PACKAGE line in the function list determines how the names are shortened - it simply removes prefixes.

For example:

    # PACKAGE{"github.com/dtromb/gogsl/ode", ["gsl/gsl_odeiv2.h"],["gsl_odeiv2"]}

shortens ode.GslOdeiv2ControlScaledNew to ode.ControlScaledNew, etc...

However, sometimes chopping off the prefix leads to name collisions, and other times packages have multiple prefixes. So, the third argument can take a list of prefixes - it will try these in left to right order.

The other part of the problem as you point out is that type symbols, constants, and anything hand-written (_type.go, _support.go) do not have these transforms applied. I've probably even been inconsistent in these in some places, as well.

I'm pretty much fine with whatever so long as it's consistent and it's easy to find the Go symbol if you know the C symbol. I'm also fairly new to Go itself, so I'm glad you're thinking about this - you'll know better than I do what Go programmers expect, or what's "go-like".

As for the name of the project, I'm more inclined to use "go-gsl" - even though sure, you know it's Go if you're using it, I think it's more clear it's a binding that way (and also it's parallel with the names of some of the API wrappers I see you've written!) If I import "go-gsl", I assume the package symbols default to gsl.*?

dtromb commented 9 years ago

@sbinet - Any further thoughts on this issue? Just pinging again, since you asked above...