May or may not be of interest, but I experimented with an alternative approach in https://github.com/myitcv/x/blob/master/immutable/_doc/immutableGen.md
Although this is where the term "immutable" gets massively overloaded, because the result of immutableGen is (as I understand it) persistent data structures. My use of the term "immutable" is more a nod to https://github.com/immutable-js/immutable-js which inspired the pattern. That caveat aside. It's a code generation approach whereby you declare immutable templates, e.g. type _Imm_Banana struct { Name string age int } You then get code generated get/set methods that respect the exported-ness of the template fields. immutableVet can then be used to verify correct use of struct fields within a package, i.e. that you don't have any non-generated code that subverts the get/set methods. You can also have "immutable" maps and slices. On Thu, 21 Nov 2019 at 16:16, <advanderv...@gmail.com> wrote: > > Dear Gophers! > > I was wonder if it possible to force immutability on the method receiver? I > know Go doesn't support immutable types and that it is possible to pass the > receiver by value but if the receiver struct has a field with a pointer type > the method may still manipulate it: > > type Counter struct { > n *int > } > > func (c Counter) Render() string { > *c.n += 1 > return strconv.Itoa(*c.n) > } > > I would like to force (or hint) the the user in writing interface{ Render() > string } implementations that don't manipulate the method receiver. So that > they can be considered 'pure' in the functional sense of the word and can be > called repeatedly without side effects. I would like the user to be able to > define implementations of interface{ Render() string }such that I can safely > call the method and use the returned string to write a http.Reponse without > it changing between requests. > > I control the way in which Render is called and I am open to crazy answers > such as: > > - Maybe it is possible to use reflect to "switch" out the value receiver for > a temporary value which is discarded after every call? > - Maybe i can use static code analysis to warn the user? How feasible is it > to prevent all cases of this happening with just static code analysis? can > this be done at runtime? > - I could instead ask the user to provide a factory function that init new > Counters but maybe very inefficient if the structs are very large (or have > many nested structs)? > > Or maybe there is some possibility that I'm missing? > > Cheers, > > Ad > > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/7ee35405-fef4-415b-ae5d-95322b4065aa%40googlegroups.com. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CACoUkn4x%2Bx4k8rQhoLVbNHeBB_-r9zAMYpXDZYhU%3DSamVEmuFg%40mail.gmail.com.
