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/1474109165.1779.1574360359927%40wamui-scooby.atl.sa.earthlink.net.
