I'm afraid your question is a bit confusing, which may account for some of
the responses you have received so far. Here is what I think you are asking
for. You want to define an interface which *your *package will use, and *other
*packages will implement. You want to put restrictions on what these
implementation can do within the methods that satisfy the interface. In
this case it is immutability. Is that correct?
If so, then I believe the simple answer is no. If packages over which you
have no control implement your interface you can not enforce what those
methods do. Your only real option is to clearly document in your interface
definition what you expect.
But that's not all that problematic. This is really true for any aspect of
the functionality implemented by an interface. Simply matching the method
signatures is enough for the compiler to allow a type to implement the
interface. But in almost every case that is not actually enough to satisfy
the intent of the interface. The coder must carefully take into account the
required documented behavior of the interface as well. If a coder chooses
to implement an interface in a way that violates the documented
requirements then they are a bad coder, and should expect bad results when
they try to use that interface. Go coders are used to reading and following
the interface requirements as documented.
On Thursday, November 21, 2019 at 11:16:37 AM UTC-5, advand...@gmail.com
wrote:
>
> 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/08be239b-f29c-451f-a8ec-90dfc7d1bbec%40googlegroups.com.
