> Eliminating code duplication shrinks the base of code that must be changed
Except go was designed a certain way that will make whatever you are
attempting to do here burdensome. We've all been there at first trying to
fit a square into a round hole, it doesn't work. Unless you start ignoring
Go type system with interface {} everywhere, you're not going to go far
trying to emulate method overloading in Go. The price of using Go is
absolutely code duplication and a certain amount of verbosity in order to
remain type safe. The only real way to achieve method polymorphism in go is
to use interfaces, since Go supports neither inheritance nor generic
programming. Go does not allow developers to write "clever" code without
sacrificing readability or compile time type safety.
Le vendredi 4 mai 2018 06:26:59 UTC+2, Louki Sumirniy a écrit :
>
> The specifics of how it is done is not as important as why to do it:
>
> I am writing this for a later project. It will need at least 5 different,
> sometimes nearly not very different, short data types. They all have the
> property of being comparable. The code that keeps them stored and sorted
> does not need to know anything other than this comparability, and to be
> able to pass the data back to the caller.
>
> I am not making claims about something, trying to sell some snake oil, I
> am attempting to solve a problem and make use of low level architecture of
> the hardware to improve performance. It worked for B-heaps so maybe MAYBE
> it will also benefit binary trees. The way some people respond you'd think
> I was running an ICO!
>
> Programming is usually 5% writing and 95% debugging. Eliminating code
> duplication shrinks the base of code that must be changed, otherwise I have
> to delve into code generators or macros. If I have an intended use for a
> library I am writing, that would require 5 different source files for each
> data type, yet 90% of the code was the same, what happens when I realise I
> made a mistake in this common code?
>
> I pretty much concluded that it is better to just pass an 8 element
> function pointer struct as value anyway. Whether the compiler does it
> differently doesn't really matter since I can't control that. What matters
> to me is that it's readable so I don't have to spend more time reading than
> understanding.
>
> On Thursday, 3 May 2018 23:40:07 UTC+3, Jan Mercl wrote:
>>
>> On Thu, May 3, 2018 at 10:14 PM Louki Sumirniy <louki.sumir...@gmail.com>
>> wrote:
>>
>> > As some here may know, I am implementing a novel binary tree based on
>> complete trees and using ideas from B-heaps in order to achieve maximum
>> data cache locality in a search and sort algorithm.
>>
>> ...
>>
>> > Note that this is not really at all an OOP paradigm that I am trying to
>> ape with this.
>>
>> ...
>>
>> > I have the base type that concerns itself with the walk, search, insert
>> and delete functions in an interface.
>>
>> ....
>>
>> > The b.Overloads - I am not sure, whether it should be pass by value or
>> pass by reference. I think pass by reference adds an extra resolution step,
>> but it is probably more expensive as every call of the functions will have
>> to perform this dereference.
>>
>> ...
>>
>> > Thanks in advance for any feedback on this.
>>
>> - Novelty is only valid when established by peer review. Self-claimed
>> novelty often means just lack of research. Even if eventually correct, it's
>> a warning sign for me meanwhile.
>>
>> - Attempts to make non-interface types in Go behave in the OOP-style
>> inheritance is usually a telling sign of using the wrong language - or
>> abusing one - to solve the problem.
>>
>> - Pass by reference has not even a well defined meaning in Go.
>>
>> No insult intended, you've explicitly asked for _any_ feedback. My
>> apologies if you feel offended anyway,
>>
>>
>> --
>>
>> -j
>>
>
--
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.
