Re: [go-nuts] Enforce immutability through static analysis

[Robert Engels]

I don't think anyone was mocking the question or thought it was ridiculous.

-----Original Message-----
From: Robert Johnstone
Sent: Nov 22, 2019 8:40 AM
To: golang-nuts
Subject: Re: [go-nuts] Enforce immutability through static analysis

This comment is a little unfair.  There was at one time efforts to allow const as part of the type system.  I believe that the specific motivation was to allow []const byte to ease conversions are eliminate conversions from strings.  The current duplication of bytes and strings packages is a bit of a smell.  

If you had instead written an example for an interface, the request would not seem so ridiculous:

  interface X {

    const f() int

  }

(Not advocating a change to the language, just pointing out that the question should not be mocked)

On Thursday, 21 November 2019 13:01:09 UTC-5, burak serdar wrote:

The way I read the original post what is being asked is, is it
possible to have the Go-equivalent of the following C++ code:

class X{
  public:
  virtual int f() const =0;
}


>
>
>
> -----Original Message-----
> >From: burak serdar <bse...@computer.org>
> >Sent: Nov 21, 2019 11:34 AM
> >To: Robert Engels <ren...@ix.netcom.com>
> >Cc: advand...@gmail.com, golang-nuts <golan...@googlegroups.com>
> >Subject: Re: [go-nuts] Enforce immutability through static analysis
> >
> >On Thu, Nov 21, 2019 at 10:25 AM Robert Engels <ren...@ix.netcom.com> wrote:
> >>
> >> I don't think we are talking about the same thing. You can certainly code an immutable object - just don't export any methods that mutate the object, nor export ANY fields.
> >
> >Correct, we're talking about different things. The question is not
> >whether you can write an immutable object (yes you can), it is whether
> >there is a way to enforce the immutability of the receiver of a
> >method.
> >
> >If the method is exported and if the receiver contains pointers, there
> >can be no guarantee that the method will not modify values reachable
> >from the copy of the receiver.
> >
> >>
> >>
> >>
> >>
> >> -----Original Message-----
> >> >From: burak serdar <bse...@computer.org>
> >> >Sent: Nov 21, 2019 11:09 AM
> >> >To: Robert Engels <ren...@ix.netcom.com>
> >> >Cc: advand...@gmail.com, golang-nuts <golan...@googlegroups.com>
> >> >Subject: Re: [go-nuts] Enforce immutability through static analysis
> >> >
> >> >On Thu, Nov 21, 2019 at 10:05 AM Robert Engels <ren...@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 <ren...@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 <bse...@computer.org>
> >> >> >> Sent: Nov 21, 2019 10:53 AM
> >> >> >> To: Robert Engels <ren...@ix.netcom.com>
> >> >> >> Cc: advand...@gmail.com, golang-nuts <golan...@googlegroups.com>
> >> >> >> Subject: Re: [go-nuts] Enforce immutability through static analysis
> >> >> >>
> >> >> >>> On Thu, Nov 21, 2019 at 9:49 AM Robert Engels <ren...@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: advand...@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 golan...@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 golan...@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 golan...@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/722064fa-60a1-4fac-a239-52e3b915de63%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/1252132353.545.1574436138453%40wamui-teddy.atl.sa.earthlink.net.