Gomobile team: we'd like to help you guys

TL;DR This is a post for the Golang team, especially for the Gomobile/Gobind one.


Well, first of all, I’d like to thank you guys for the extraordinary work made with gobind and, of course, gomobile tool: the possibility of building a framework/library that can be embedded in an iOS and/or Android app is amazing.

But, unfortunately, for now, it has too many limitations in terms of Type restrictions. For example, you cannot cross-bind a function that takes or returns a struct type. And this is very very limitative though.

So, the point is, How can we (the gopher community) help you guys in moving these tools forward ? Do you have any guideline, or/and a roadmap (I’m not saying issues because I know we can find those on GitHub) that we can follow in order to do that ?

This will be really great, and I’ll be really excited doing that though.

2 Likes

Lifting the type restrictions on gobind requires first designing what the interface will look like in Java and Obj-C, and then implementing it in the code generator.

We have some ideas for what we could do with the currently unsupported types, but haven’t put much time into it. There are several things that need to be considered. In particular: these high-level cross-language function calls are always going to be relatively expensive compared to a normal function call, so it’s not just a matter of finding a matching type that will work, but designing one that is useful.

For example, for a function that returns a struct S, the easy thing to do in Java is to return the same type as we would for *S. That is, a Java class with getters and setters. However, that’s not particularly useful. It increases type coverage, but doesn’t offer any more useful features to someone designing a package for gobind.

More useful could be, given:

type S struct {
  X int
  Y string
}

func F() S { ... }

gobind could generate the Java

class S {
  public int X;
  public String Y;

  public static S F() { ... }
}

This would mean returning S instead of *S copies the fields across the language boundary at each use, which in some cases would be more expensive and in some cases less expensive than the referencing we do for *S. What are the implications of this? Where is some code that could use this well? (This is very similar to how nano protobufs work: https://github.com/google/protobuf/tree/master/javanano, so code that uses it could be used as an example.)

To do this, someone has to take the time to think this through and write it down. Issues like: what is the Java class called? (Does it conflict with the existing *S generated code?) A proposal would almost certainly involve building a prototype first and finding a use for it. I expect it to be quite a lot of work. If you would like to take it on, please go for it.

There are several other type restrictions well worth lifting, that are filled with a lot of corner cases. In particular, named types. It’s entirely possible, it’s just a lot of detail work.

The first step is becoming very familiar with go/types. An intuitive understanding of Go’s type system is not a good place to start with this sort of work because it is easy to miss uncommon details. Reading through the go/types API and its implementation is probably the best way to learn the details.

3 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.