On Wednesday, 1 November 2017 12:19:19 UTC+1, JuciÊ Andrade 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.
>
This is a nice argument. But please consider a small variation on it:
Let's start of with as you did: r is a pointer and you check its nilness:
r *myType
if r != nil {
r.doSomething()
}
"Then, years later, other programmer in my team decides to [...]
[add one more level of indirection] to better capture a new
understanding of the problem at hand, changing the type of r to:"
r **myType
"Subtly, the meaning of"
if r != nil {
r.doSomething()
}
"changes. Under the right circumstances our software starts to
behave strangely. What?"
Of course it will! And this is (I hope undoubtedly) not a language
design error. Of course it would sometimes be handy to be able
to write
var a ***int
if a _!=_ nil { ... }
with an operator _!=_ with semantics like
if a != nil && *a != nil && **a!=nil { ... }
(all the way down).
But there currently is no such deep-down-comparison operator
(and it presumably would be hard to design a consistent one).
What you have been asking for is some magic to unpeel the topmost
interface level. But where to stop? How should
var b *myInterface
if b != nil { ... }
behave? Check if b actually is non-nil, then check if the interface
itself is non-nil and then peek inside the interface and check if there
is a non-nil value?
Just because a single example demonstrates that some behaviour
would be helpful and help mitigate an error does not mean it does
not open a different can of worms.
V.
--
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.
