On Wednesday, November 1, 2017 at 3:37:54 PM UTC+2, Ayan George wrote:
>
>
>
> On 11/01/2017 07:18 AM, oju...@gmail.com <javascript:> wrote:
> > Ayan, imagine I am part of a development team. In our program I have a
> > pointer r:
> >
> > r *myType
> >
> > My variable r can be nil, because that is a valid situation. It is used
> > in dozens of places, like this:
> >
> > if r != nil {
> > r.doSomething()
> > }
> >
> > That is a very usual idiom, no only in Go, but in many languages. Every
> > programmer is acquainted to that.
> >
> > Then, years later, other programmer in my team decides to create an
> > interface to better capture a new understanding of the problem at hand,
> > changing the type of r to:
> >
> > r myInterface
> >
> > Subtly, the meaning of
> >
> > if r != nil {
> > r.doSomething()
> > }
> >
> > changes. Under the right circumstances our software starts to behave
> > strangely. What?
> >
> > This problem is dangerous because it is so subtle. We will read our old
> > code time and again to no avail, because everything seems fine and no
> > one has changed that "if r != nil r.doSomething" in ages.
> >
>
> I think I understand what you're saying. The thing is: You changed the
> type of r and I don't believe anyone ever promised that you can change
> the type of a variable to an interface AND preserve its behavior.
>
> Would you expect r to behave the same if you changed it from type string
> to an int?
>
Point is, in that case compiler would catch it for you and you wouldn't be
able to compile until you fix all the parts of the code which now doesn't
make sense. Not so in the case JuciÊ Andrade pointed out.
ain
--
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.
For more options, visit https://groups.google.com/d/optout.
