undefined | Better HN

0 pointslaumars8y ago0 comments

> You're not "checking the value of a property after you've nil'd the parent object", you're checking if you were given a nil.

Sorry, it's a method not a property, but I think my point remains valid with regards to the example in that article. Just to be clear, I'm not trying to defend nil here, but I do think it's important to understand the issue because I think the authors code would have failed regardless of the language. So Let's break the code down: first they create a struct exposed via an interface{}

    type T struct{}

    func (t T) F() {}

    type P interface {
        F()
    }

func newT() *T { return new(T) }

Then they create an initialized variable that object type:

    t := newT()
    t2 := t

...and set that interface{} to nil:

    if !ENABLE_FEATURE {
            t2 = nil
    }

Then they check the value returned from a method of the struct - bare in mind this is after the struct has been `nil`ed:

    thing := factory(t2)
    fmt.Println(thing.P == nil) // returns nil

If there's a likelihood that they could be working with nil interfaces then they should be first checking the value of the interface before checking the value of the methods within it. Most OOP languages would raise an exception / print runtime error (in the case of JIT dynamic languages) or downright crash if you tried to access methods or properties of a nil / null / whatever type. So I'm not defending Go's behavior but their example is peculiar to say the least.

That all said, I do feel your examples are a lot more relevant to this discussion than the one that prompted the discussion to begin with.

0 comments

coldtea8y ago

>Most OOP languages would raise an exception / print runtime error (in the case of JIT dynamic languages) or downright crash if you tried to access methods or properties of a nil / null / whatever type.

Most OO languages wont report an interface as non null if its value is null. Go will.

laumarsOP8y ago

Indeed - I wasn't defending Go's behavior here. I was just replying to your question about whether it is an edge case or not. Since the code would be broken in any OOP language I do consider this to be an edge case. But that doesn't mean I like nor would defend Go's nil type system.

masklinn8y ago

> Sorry, it's a method not a property, but I think my point remains valid with regards to the example in that article.

Not really, Go supports (and encourages properly handling) nil method receivers.

> Most OOP languages would raise an exception / print runtime error (in the case of JIT dynamic languages) or downright crash if you tried to access methods or properties of a nil / null / whatever type.

Setting aside the fact that this is not quite true[0], there is a gulf between "failing" as a clear runtime (or compile-time) error at the point of an incorrect invocation, and "failing" by silently yielding a nonsensical state and possibly but not necessarily faulting at some other point later on. PHP gets regularly and deservedly panned for the latter.

[0] nil is a message-sink in obj-c (any message can be sent to nil and will be a no-op returning nil), and you can make Ruby or Smalltalk behave that way (or any other) as their nil is a regular object with a normal type which you can go and extend

laumarsOP8y ago

> there is a gulf between "failing" as a clear runtime (or compile-time) error at the point of an incorrect invocation, and "failing" by silently yielding a nonsensical state

Of course. But then I also made that point too. Frequently in fact and in the very post you're replying to as well. Plus also in the other reply that echoed the same point you're raising here. I'm not justifying Go's behavior here. Absolutely not! It is unexpected and bad. But we have already established and agreed on that point so moved onto another question regarding whether the authors example is an issue that is likely to arise often. I was attempting to explain why I felt it was a poor example and not trying to justify Go's behavior - which at risk of repeating myself: we all already agree is bad.

j / k navigate · click thread line to collapse

0 pointslaumars8y ago0 comments

> You're not "checking the value of a property after you've nil'd the parent object", you're checking if you were given a nil.

    type T struct{}

    func (t T) F() {}

    type P interface {
        F()
    }

func newT() *T { return new(T) }

Then they create an initialized variable that object type:

    t := newT()
    t2 := t

...and set that interface{} to nil:

    if !ENABLE_FEATURE {
            t2 = nil
    }

Then they check the value returned from a method of the struct - bare in mind this is after the struct has been `nil`ed:

    thing := factory(t2)
    fmt.Println(thing.P == nil) // returns nil

That all said, I do feel your examples are a lot more relevant to this discussion than the one that prompted the discussion to begin with.

0 comments

coldtea8y ago

Most OO languages wont report an interface as non null if its value is null. Go will.

laumarsOP8y ago

masklinn8y ago

> Sorry, it's a method not a property, but I think my point remains valid with regards to the example in that article.

Not really, Go supports (and encourages properly handling) nil method receivers.

> Most OOP languages would raise an exception / print runtime error (in the case of JIT dynamic languages) or downright crash if you tried to access methods or properties of a nil / null / whatever type.

laumarsOP8y ago

> there is a gulf between "failing" as a clear runtime (or compile-time) error at the point of an incorrect invocation, and "failing" by silently yielding a nonsensical state

j / k navigate · click thread line to collapse