-
Notifications
You must be signed in to change notification settings - Fork 81
How to properly handle interfaces? #6
Comments
IBuildable sounds like the right way to go about this. I originally implemented these GInterfaces that way with the anonymous fields because I didn't want to reimplement a million different functions for each interface, which all performed the exact same code, but taking different types as the receiver. Keeping, for example, the CellLayout type as a struct, with all its normal implemented fields, and then adding the go interface ICellLayout to everything which implements sounds like a much better way to go about this. It would also simplify all of the new wrap*() functions. |
Looking at it some more I understand better some of the original decisions, and it might actually be best to stick with the struct and interface model, but update the wrap methods. For example:
And then the wrap methods could be implemented kind of like
This code isn't really tested and so might contain some errors, but it should highlight the approach that I have in mind, which would hopefully prevent duplication of interface functionality. |
Oh I remember why I had chosen to do it that way originally. If some object implements Buildable and provides function GetName(), I want to be able to call obj.GetName() instead of using obj.GetBuildable().GetName(). If Go allowed defining functions with interfaces as receivers, this wouldn't be an issue. |
I came up with an example for a solution in my fork. Basically I added |
Fix pull request conformal#4
In particular I'm interested in implementing the
GtkBuildable
interface, which is implemented by a crap-ton of things. However, my initial attempt based on existing code to implement it for Widget results in a mess of "ambiguous selector v.GObject" and "too few values in struct initializer" errors.Thinking about it some more, I'm not sure why it wouldn't be feasible to just create an
IBuildable
interface implementingtoBuildable()
, then define that for each object that implements it. Is there a reason that, for example, ComboBox is implemented the way that it is with theCellLayout
anonymous field? Is havingICellLayout
not enough?The text was updated successfully, but these errors were encountered: