On Thu, Nov 21, 2019 at 10:05 AM Robert Engels <reng...@ix.netcom.com> wrote:
>
> To clarify - the author of the package enforces immutability. With Go’s
> design this can be a simple comment on the field. The package shouldn’t be
> that large where this doesn’t work.
The original problem remains: there is no way to enforce an immutable receiver.
>
> > On Nov 21, 2019, at 10:58 AM, Robert Engels <reng...@ix.netcom.com> wrote:
> >
> >
> > Correct, but if the receiver method is mutating it, then it is not an
> > immutable object.
> >
> >
> >
> >
> > -----Original Message-----
> >> From: burak serdar <bser...@computer.org>
> >> Sent: Nov 21, 2019 10:53 AM
> >> To: Robert Engels <reng...@ix.netcom.com>
> >> Cc: advanderv...@gmail.com, golang-nuts <golang-nuts@googlegroups.com>
> >> Subject: Re: [go-nuts] Enforce immutability through static analysis
> >>
> >>> 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/2080138990.1391.1574355466613%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/CAMV2RqoQT9FFFotRMhcWunDN5R9dzSXtExkp2%3D1eac_xFJ5gPQ%40mail.gmail.com.
