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