This is a code smell for me:
type BAST interface {
AddRow() error
IsLeft(interface{}, Cursor) bool
IsRight(interface{}, Cursor) bool
IsEqual(interface{}, Cursor) bool
IsEmpty(Cursor) bool
…
Interfaces should be small. This looks like a class definition which isn’t
a Go pattern. Also I would avoid interface{} if possible, and the function
types seem more complicated than necessary. I’m not convinced your
types/API are optimal.
I still don’t exactly understand the goal, but this is my thinking about
the playground example: https://play.golang.org/p/KNdrYbebpuo
Matt
On Monday, April 23, 2018 at 3:46:03 AM UTC-5, Louki Sumirniy wrote:
>
> 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, [email protected] 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
