I spent two hours wrestling with this, but as you can see in this playground, the method I proposed totally works: https://play.golang.org/p/FMvisWS9tuP
I propose that the type builtin when dealing with functions should have an extension made to it to add the method binding to the type signature so this workaround is not necessary. It would not break the spec, old code, or any of the goals that Go works towards. It would actually help with getting adoption by OOP programmers, in my view, because method overriding for this exact purpose of enabling the abstraction of backend type stuff (in my case it's just an array, but it could easily be a storage protocol or network protocol) would help immensely in implementing pluggable architectures. On Monday, 23 April 2018 08:23:24 UTC+3, Louki Sumirniy wrote: > > https://github.com/golang/go/issues/24996#issuecomment-383424588 > > It seems that (Type).FuncName in the assignment binds to the struct... I > am glad I found an answer so quickly because my hackish solution was gonna > be implemented today. > > On Monday, 23 April 2018 02:20:47 UTC+3, Louki Sumirniy wrote: >> >> You will see in the code I linked in the previous message that I already >> do have the interfaces in there. They can't be bound to the struct directly >> because I can't specify a function type that matches the signature, thus >> the use of a wrapper, and the interface types in the parameters. >> >> I just can't override them, and the great bulk of the code is not these >> small set of initialiser/allocator/comparator/getter/setter functions, so >> to have to search and replace through the whole thing, and maintain >> multiple nearly identical pieces of source code for the sake of 7 functions >> that are all very short, and differ between these versions, when everything >> else is the same... then I find a bug in one version, in the outer shell of >> the code and I have to merge every change of it into the other 5 >> versions... it's extremely cumbersome. >> >> The solution I have shown is just the first thing that looks to me like >> it would work. I have read tons of tutorials about composition and >> polymorphism and embedding in go, and in the end I pieced this together >> from several different things I learned. I tried several different things. >> It just makes absolutely no sense to have to go through and add a load of >> maintenance work to my code just so I can create, expand, read, write and >> compare values stored within the otherwise identical data structure. >> >> On Monday, 23 April 2018 01:44:43 UTC+3, matthe...@gmail.com wrote: >>> >>> Interface types are useful when the data structure is varied. Why not an >>> interface containing these varying functions as methods instead of function >>> types? >>> >>> Matt >>> >>> On Sunday, April 22, 2018 at 5:20:12 PM UTC-5, Louki Sumirniy wrote: >>>> >>>> I essentially am trying to find an effective method in Go, preferably >>>> not too wordy, that lets me create an abstract data type, a struct, and a >>>> set of functions that bind to a different data type, and that I can write, >>>> preferably not in too much code, a change that allows the data type of the >>>> embedded data to be changed. It's basically kinda inheritance, but after >>>> much fiddling I found a hackish sorta way that isn't *too* boilerplate >>>> filled: >>>> >>>> type nullTester func(*Bast, uint32) bool >>>> >>>> type Bast struct { >>>> ... >>>> isNull nullTester >>>> ... >>>> } >>>> >>>> func isNull(b *Bast, d uint32) bool { >>>> return d == 0 >>>> } >>>> >>>> func NewBast() (b *Bast) { >>>> ... >>>> b.isNull = isNull >>>> ... >>>> } >>>> >>>> // IsNull - tests if a value in the tree is null >>>> func (b *Bast) IsNull(d uint32) bool { >>>> return b.isNull(b, d) >>>> } >>>> >>>> >>>> Now, bear in mind I haven't shown all of the code. But there is a slice >>>> array in the Bast struct, and I it is defined as an interface{} and isNull >>>> is one of a set of operators that have to be written to match the type >>>> used >>>> in the slice store, this might be a bad example because it doesn't >>>> actually >>>> act on the interface typed slice, but the point here is just this: >>>> >>>> It does not appear to be possible to make the type specification from >>>> the top line match the function signature of the type-bound function in >>>> the >>>> bottom of the code snippet. I haven't been able to find anything that >>>> shows >>>> that a func type can have a method binding. >>>> >>>> https://github.com/calibrae-project/bast/blob/master/pkg/bast/bast.go >>>> is where my WiP lives. This slightly hacky solution seems sound to me, I >>>> just don't like to be forced to use workarounds like this. If a type >>>> signature cannot be written that matches a method, yet I can do it this >>>> way, I don't see what purpose this serves as far as any kind of >>>> correctness >>>> and bug-resistance issues go. I would have to deal with a lot more >>>> potential bugs if I had to concretely implemennt this library for the sake >>>> of 1 slice and 7 functions out of a much larger library that conceptually >>>> is intended to only deal with comparable, mainly numerical values anyway. >>>> >>> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
