On 22 April 2018 at 23:20, Louki Sumirniy
<louki.sumirniy.stal...@gmail.com> 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.
I don't really understand why you think you want all those function types.
Your code seems to mix concerns quite a bit, but interfaces in Go are generally
closely focused on a particular thing.
I don't understand anything about your algorithm, but ISTM you could
do something like this:
https://play.golang.org/p/wv0T8T8Ynns
Some changes I made in doing that;
- unexported a load of identifiers that really don't deserve to be
part of the public API
- made Cursor into a lightweight by-value type
- defined a Store interface that doesn't require knowledge of the
Cursor data type.
A few other observations:
- requiring a value type to know whether an item is null or not does
not seem great
when you're storing integers - who is to say that the zero uint32 is
not a valid thing to store?
- requiring callers to know about AddRow (and hence how the tree is
organised) does
not seem ideal.
- there's no way to search for or insert items, but I guess you'll be
doing that later.
- it looks like your algorithm will always use a power-of-two multiple
of the element size,
which could end up very inefficient when the tree is large.
cheers,
rog.
--
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.
