On Thu, Nov 21, 2019 at 9:49 AM Robert Engels <reng...@ix.netcom.com> wrote:
>
> They can't unless the instance field is exported. Just hide it via
> encapsulation with accessors.
Can't do that with a receiver. All methods of a type are in the same
package as the type, so all fields are visible to the receiver.
>
> -----Original Message-----
> From: advanderv...@gmail.com
> Sent: Nov 21, 2019 10:15 AM
> To: golang-nuts
> Subject: [go-nuts] Enforce immutability through static analysis
>
> 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/1622995561.1365.1574354931169%40wamui-scooby.atl.sa.earthlink.net.
--
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/CAMV2RqrFuM%3DqYyWK_CdFev4t1deBr1tvgHtWYF-f8N37Ks%2BvaA%40mail.gmail.com.
