4 ms·
> I don't see how the go approach makes anything simpler. The "append" builtin doesn't "invoke" anything on the nil pointer. It's more or less (in Java-ish pse
by barsonme 4y ago
> I don't see how the go approach makes anything simpler.
The "append" builtin doesn't "invoke" anything on the nil pointer. It's more or less (in Java-ish pseudocode):
static Slice<T> append(Slice<T> s, items ...T) {
if (s == null) {
Slice<T> newSlice = new Slice<T>(items.size())
newSlice.pushBack(items)
return newSlice
}
if s.hasEnoughCapcityFor(items.size()) {
s.pushBack(items)
return s
}
Slice<T> newSlice = new Slice<T>(s.size() + items.size())
newSlice.pushBack(s)
newSlice.pushBack(items)
return newSlice
}
which is a perfectly reasonable utility function in pretty much any language. See, e.g., realloc(3).
> Value semantics are simply that the value of an object is all that matters. For example, two int objects '5' are the same from a value-semantic perspective. I guess this implies all objects have some value.
>
> Equatability is a requirement of objects in java. Not all types of objects are equatable beyond their identity (some unique identifier) though. For example, how do you equate two functions? To me this parallels the decision in go to make zero values a thing beyond a runtime error.
In Go, having a "meaningful" zero value for a type means that you don't need to initialize the type before using it. For example:
var b bytes.Buffer
b.WriteString("hello, world")
instead of
b := bytes.NewBuffer(nil)
b.WriteString("hello, world")
Or, as another example:
type BinarySearchTree struct { ... }
func (b *BinarySearchTree) Contains(key string) bool {
if b == nil {
return false
}
[...]
}
Go makes this possible by not requiring constructors like other languages do (e.g., Java).