Thank you for the responses! I understand that i'm trying to do something
that the language doesn't really support, and that is fine; i'm a huge
advocate of Go so i'm not trying to point out language weaknesses.
In my i'm dictating the interface{} that the user should implement to allow
its "component" (the struct implementing the interface) to be rendered so
it's hard to enforce immutability with setters and getters since the
properties are in control of the user so i can't dictate an interface for
that upfront.
On Thu, Nov 21, 2019 at 7:19 PM Robert Engels <reng...@ix.netcom.com> wrote:
>
> Yes, I agree. But in some sense, a developer needed to add the 'const',
> i.e. decide that the method was immutable as part of the design (and since
> Go doesn't have inheritance it is less important). Go doesn't support this
> through syntax/compiler it supports it through design philosophy - if the
> packages are well done, and right-sized, the "immutable design" is easily
> "enforced & validated". I also think this can lead to easier to understood
> designs - rather than just slapping a bunch of const declarations.
>
> Java is in a similar boat (a bit more difficult since it has inheritance),
> and it is not a problem with proper design. There are TONS of "immutable"
> Java libraries.
>
> Just my opinion of course :)
>
>
>
>
> -----Original Message-----
> >From: burak serdar <bser...@computer.org>
> >Sent: Nov 21, 2019 12:00 PM
> >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 10:39 AM Robert Engels <reng...@ix.netcom.com>
> wrote:
> >>
> >>
> >>
> >> I'm sorry, but isn't the way you enforce immutability is that you don't
> code mutating exported methods? The author controls the package code.
> Immutability is usually only a concern outside the package, and that is
> clearly supported.
> >
> >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 <bser...@computer.org>
> >> >Sent: Nov 21, 2019 11:34 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 10:25 AM Robert Engels <reng...@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 <bser...@computer.org>
> >> >> >Sent: Nov 21, 2019 11:09 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 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/CAMV2RqqYdfYdEVbGrOtNiSa45Vgn6ZCibP3Gqrn%2BRe-%2BmFJVBg%40mail.gmail.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/CAHSGUeJ-LgcwmxGLASp-hcDLGvYkMEiVRd2n6gn9HCwUKDSHjw%40mail.gmail.com.
