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.
