-
Notifications
You must be signed in to change notification settings - Fork 14
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Structs now inspect the value before each key, because yielding of the key must of course be skipped if the value is to be skipped. And yet, we're not done here, and that test is commented out for a reason! This is more complicated than for e.g. stdlib json.Marshal -- we have to emit length information at the beginning of an object. And this, in turn, is capital-H Hard. Emitting the correct length information *up front* will require significantly more code changes, and they're a tad controvertial. We have to inspect *all* the fields to see if they're going to be skipped. And strangely, I think we're going to have to do that twice. Checking for the fields to skip must happen at the top, that much is clear; but then to remember which ones we already know will be skipped would require O(n) memory in the length of the struct... which would imply a heap allocation to track! (Worrying about heap allocs is not news in the refmt project because of our stepfunc design, but it's interesting to note we'd be in trouble anyway: Go actually always lets runtime-sized slice creation escape to heap: golang/go#20533 .) So. An O(2n) runtime is going to be a better trade than slipping from constant to O(n) memory. Hrmph. Anyway, that bit will be in the next commits. Signed-off-by: Eric Myhre <[email protected]>
- Loading branch information
Showing
3 changed files
with
78 additions
and
12 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,42 @@ | ||
package obj | ||
|
||
import "reflect" | ||
|
||
// The missing definition of 'reflect.IsZero' you've always wanted. | ||
// | ||
// This definition always considers structs non-empty | ||
// (checking struct emptiness can be a relatively costly operation, O(size_of_struct); | ||
// all other kinds can define emptiness in constant time). | ||
func isEmptyValue(v reflect.Value) bool { | ||
switch v.Kind() { | ||
case reflect.Array, reflect.Map, reflect.Slice, reflect.String: | ||
return v.Len() == 0 | ||
case reflect.Bool: | ||
return !v.Bool() | ||
case reflect.Int, reflect.Int8, reflect.Int16, reflect.Int32, reflect.Int64: | ||
return v.Int() == 0 | ||
case reflect.Uint, reflect.Uint8, reflect.Uint16, reflect.Uint32, reflect.Uint64, reflect.Uintptr: | ||
return v.Uint() == 0 | ||
case reflect.Float32, reflect.Float64: | ||
return v.Float() == 0 | ||
case reflect.Interface, reflect.Ptr: | ||
return v.IsNil() | ||
} | ||
return false | ||
} | ||
|
||
// zeroishness checks on a struct are possible in theory but we're passing for now. | ||
// There's no easy route exposed from the reflect package, due to a variety of reasons: | ||
// | ||
// - The `DeepEqual` method would almost suffice, but we'd need one that takes | ||
// `reflect.Value` instead of `interface{}` params, because we already have | ||
// the former, and un/re-boxing those into two `interface{}` values is two | ||
// heap mallocs and that's a wildly unacceptable performance overhead for this. | ||
// `DeepEqual` calls `deepValueEqual`, which does what we want, but... | ||
// - We can't easily copy the `deepValueEqual` method. It imports the unsafe | ||
// package. This is undesirable because it would reduce the portability of refmt. | ||
// | ||
// It's possible we could produce a struct isZero method which is *simpler* than | ||
// `deepValueEqual`, because we can actually just halt on any non-zero pointer, | ||
// and without any need for following pointers we also need no cycle detection. | ||
// But this is an exercise I'm leaving for later. PRs welcome if someone wants it. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters