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.
