7 ms·
nil doesn't "expand", it's just what it is. You have to bear in mind that methods are roughly syntactic sugar from func (o *Object) ReturnSomething() int t
by Vendan 10y ago
nil doesn't "expand", it's just what it is. You have to bear in mind that methods are roughly syntactic sugar from
func (o *Object) ReturnSomething() int
to
func ReturnSomething(o *Object) int
In the first case, it may "seem" that a nil Object would be invalid, but in the second case it's obviously valid, and makes complete sense. It may be described as a "wart", but it makes complete sense to me. The issue is, in my opinion, that people drag their own expectations into programming languages as they learn them.
- pcwalton 10y agoIn this case, Java and C# have the same feature and don't have this behavior around null. I think it's reasonable for people who have seen identical features in other languages to expect similar behavior when learning new ones.
- Vendan 10y agoThey don't have the same feature of "I can call a method on a null value", at least, not that I've seen... You are calling them identical features when the fact is that they aren't. C# and Java both have generics, do they perform identical? Haskell has generics too, but I bet they'd throw a shit-fit if you tried to say "Oh, C# has generics too, so why would I bother with Haskell?"
- catnaroek 10y agoYou can call a method on a null value in Java and C#. It's perfectly defined behavior: throwing a NullPointerException.
- Vendan 10y agoyes, and it's a completely different behavior then Go, where it's perfectly defined as well: you call that method with a nil pointer as the receiver. Please don't act like those 2 behaviors are anywhere near similar.
- pcwalton 10y agoThe ability to call a method on a nil receiver doesn't have anything to do with what comparisons should do. Semantically, the question is whether == should compare the values or the vtables. In no other language I know of does it compare vtables.
- prodigal_erik 10y agoIf x.Foo() and y.Foo() do different things and return different values, clearly x != y, and golang needs some kind of SQL-style is-null check rather than using equality to check for null. But dynamic dispatch on "what type of object do I not have?" is still a damn weird thing to want.
- Vendan 10y agoHaving dealt with languages that don't, I much prefer ones that do. The thing is, most languages DO basically check vtables, in that 2 values with different types will never be equal (unless there is implicit casting or some kind of equality override). For instance, 1 == "1" is valid, and true, in PHP, even though that is less then ideal. The difference, of course, is that most of those checks are done at compile time in many languages. Go will do some checks at compile time, but it's specifically unable to do some of them due to the "dynamics" of how interface variables work.
- slrz 10y agoInterface comparisons check both, the value and the dynamic type. Describing that as "comparing vtables" is misleading. It the types don't match, the operands are not considered equal. Type and value have to match for two interface values to be equal. How does that not make sense? For mismatched dynamic types you can't meaningfully compare the values in the general case, so of course you need to consider types.
- pcwalton 10y ago> Type and value have to match for two interface values to be equal. How does that not make sense? Because people expect == to compare values, not types. Nobody has ever questioned this behavior in Java and C#.