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.
