I should just add one more thing, something I discovered when I saw the
cete wrapper for the dgraph's badger KV store: https://github.com/1lann/cete
If you design your interfaces carefully, and make it so that any function
that does not by necessity return some other type, passes through the
pointer receiver to the caller. These functions can be strung together in
long chains, here is an example from a test on one type I have made that
uses this design pattern:
fmt.Println(*NewLockedBuffer().FromRandomBytes(23).FromBytes(NewBytes().FromString(A)).ToBytes().ToString())
By designing it so that type conversions can pass through an intermediate
type you can push data into and out of your variables, and most
importantly, if you make a constructor ( NewLockedBuffer() ) and then you
can write a single function that loads a specific member of the struct, and
thus for an object with multiple values, it is functionally equivalent to
the 'default parameter unless specified' model that you get with named
parameters like in Python and other similar languages. Except it's far
clearer and reads very well for a human.
One caveat to this design pattern I have noticed, however, because I am
writing code working with the memguard library, is that you probably should
be very specific in each of the functions whether it copies, references or
relocates data from one structure to another. A lack of clarity about this
could cause all kinds of nasty side effects and complex, hard to solve bugs.
On Friday, 24 August 2018 14:47:21 UTC+2, Louki Sumirniy wrote:
>
> This is in the next section but it's probably even more important:
>
> There is one more aspect of naming to be mentioned: method lookup is
> always by name only, not by signature (type) of the method. In other words,
> a single type can never have two methods with the same name. Given a method
> x.M, there's only ever one M associated with x. Again, this makes it easy
> to identify which method is referred to given only the name. It also makes
> the implementation of method invocation simple.
>
> The previous section does explain why this decision was made, it makes it
> far simpler to write tools to manipulate or analyse the code. One name =
> only one variable, never any ambiguity to resolve, and this applies also to
> the human reading it.
>
> In go you can make functions that accept a slice of interface{}, and in
> theory you could use this with a switch and either strings or predefined
> constants (with iota) to create functions that you can interpret any set of
> parameters with the caveat that a parameter must always be passed to
> identify each bit of data so you can type assert it.
>
> On Friday, 24 August 2018 14:26:48 UTC+2, Masoud Ghorbani wrote:
>>
>> I found this <https://talks.golang.org/2012/splash.article>talks which
>> Rob Pike at syntax
>> <https://talks.golang.org/2012/splash.article#TOC_10.>section
>> explained why they omitted default function arguments.
>> Thanks all about this discussion.
>>
>> On Friday, August 24, 2018 at 5:21:37 AM UTC+4:30, andrey mirtchovski
>> wrote:
>>>
>>> > You're right but I think developers of Go can think about that because
>>> its benefits are obvious.
>>>
>>> can you please enumerate those benefits? many gophers are not
>>> convinced they are obvious.
>>>
>>
--
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.
