If you are willing to include some global state to your package, you could
always have memoizing logic occur outside of the Number type. That is - you
could still have every Number be passed around by value, but for
calculating sqrt you'd check some threadsafe global state and either return
a
Hello Everyone,
I'm maintaining an internet site that hosts Go-based tools/libraries.
They're served using the git ssh protocol, not https. There is a subset of
the site that works via https, so the module proxy protocol is implemented.
https://pkg.go.dev/cmd/go#hdr-Module_proxy_protocol
When
I have this package: https://pkg.go.dev/github.com/keep94/sqroot, which
computes square roots to arbitrary precision. The Number type is a value
type that represents a square root value. Early on it made sense to make
Number be an immutable value type because it represents an immutable value
Key sizes 4 and 8 have special case hashing code.
They are intended for int32, int64, and pointers, but your [4]byte and
[8]byte take advantage of it as well.
On Sunday, March 26, 2023 at 3:05:52 AM UTC-7 Amit Lavon wrote:
> Hi gophers,
>
> Some code I am writing uses byte-arrays ([X]byte) as
Hi,
Try to write readable code. If your function modifies any of its
parameters, make it obvious. Name the function properly and/or write a
comment. If the function does not modify its parameters, make it obvious
too. There is no hard rule on this one. Sometimes it makes sense to use
pure
Hello,
I have found that I have a tendency to try to code non-method funcs in a
pure way (functionally speaking - so that the caller will not modify any of
its params). I know it is possible to pass a pointer (or slice or map - is
that all of them?) as a function param and then modify it in
