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 <javascript:>>
> > >Sent: Nov 21, 2019 11:34 AM
> > >To: Robert Engels <ren...@ix.netcom.com <javascript:>>
> > >Cc: advand...@gmail.com <javascript:>, golang-nuts <
> golan...@googlegroups.com <javascript:>>
> > >Subject: Re: [go-nuts] Enforce immutability through static analysis
> > >
> > >On Thu, Nov 21, 2019 at 10:25 AM Robert Engels <ren...@ix.netcom.com
> <javascript:>> 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 <javascript:>>
> > >> >Sent: Nov 21, 2019 11:09 AM
> > >> >To: Robert Engels <ren...@ix.netcom.com <javascript:>>
> > >> >Cc: advand...@gmail.com <javascript:>, golang-nuts <
> golan...@googlegroups.com <javascript:>>
> > >> >Subject: Re: [go-nuts] Enforce immutability through static analysis
> > >> >
> > >> >On Thu, Nov 21, 2019 at 10:05 AM Robert Engels <ren...@ix.netcom.com
> <javascript:>> 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 <javascript:>> 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 <javascript:>>
> > >> >> >> Sent: Nov 21, 2019 10:53 AM
> > >> >> >> To: Robert Engels <ren...@ix.netcom.com <javascript:>>
> > >> >> >> Cc: advand...@gmail.com <javascript:>, golang-nuts <
> golan...@googlegroups.com <javascript:>>
> > >> >> >> Subject: Re: [go-nuts] Enforce immutability through static
> analysis
> > >> >> >>
> > >> >> >>> On Thu, Nov 21, 2019 at 9:49 AM Robert Engels <
> ren...@ix.netcom.com <javascript:>> 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 <javascript:>
> > >> >> >>> 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 <javascript:>.
> > >> >> >>> 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 <javascript:>.
> > >> >> >>> 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 <javascript:>.
> > >> >> > 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.
