On 25 April 2018 at 08:05, Louki Sumirniy <louki.sumirniy.stal...@gmail.com> wrote: > https://stackoverflow.com/questions/6531543/efficient-implementation-of-binary-heaps > > Pretty much what I'm working on here is this, except with left to right sort > instead of vertical. I think this guy's work will help me iron out the > performance issues.
You do know that heaps aren't a great data structure for searching, right? > Another thing, that is more on topic more specifically, is that collections > of interface methods introduce a significant overhead, compared to simply > passing the pointer to the structure as a parameter. I am thinking that > maybe a way to hide this parameter passing is by using closures, which bind > in the namespace from a hypothetical initialiser function, without actually > having to specify the pointer passing across. The structure is created and > allocated by the initialising function (constructor, if you like) and > because all of the functions are declared within the namespace as closures, > the compiler implicitly passes the pointer to the struct without having to > specify it. You don't need to do this. You're still thinking in traditional OO terms. I'd suggest trying to think in a more Go like way instead. FWIW I tried to point you in a more sensible direction with this code: https://play.golang.org/p/wv0T8T8Ynns > I don't know exactly what FP paradigm says about structures and collections > of functions exactly, as prima facie it looks like OOP. But closures are a > uniquely FP mechanism, and really they are just a way to merge namespaces, > and by doing this we don't have to pass the pointer to the function > explicitly, as it is already accessible. What gives you the idea that closures are a uniquely FP mechanism? 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.
