Unexport all testing Aggregation and AggregationValue implementations about opencensus-go

[rakyll]

As well as some testing helpers such as RestartWorker.

[acetechnologist]

• AggregationDistributionValue and AggregationCountValue are not intended for testing only. They will be used by the exporters (stackdriver, zpages...).

• RestartWorker is for testing. It is already used in:
  https://github.com/census-instrumentation/opencensus-go/blob/master/plugins/grpc/stats/client_handler_test.go
  https://github.com/census-instrumentation/opencensus-go/blob/master/plugins/grpc/stats/server_handler_test.go

[rakyll]

I wonder whether AggregationValue and Aggregation can export their APIs. Then, we can organize the testing-focused implementations to stats/statstest, in the same fashion as http/httptest.

The package's surface layer is too noisy for the user to be able to focus on the essential and get started. I think we can improve it easily by the stats/statstest package.

[acetechnologist]

Not sure I understand what you mean by "can export their APIs".
AggregationValue is an interface where the other libraries don't need access to any of their methods.

However export libraries will need access to some other non common methods implemented by AggregationCountValue, AggregationDistributionValue which are "subclasses" of that interface.

The problem is that Go doesn't have generics and methods on AggregationDistributionValue need to return a different types than the methods on AggregationCountValue.

/cc @jcd2 as it might be of interest to him

[rakyll]

A named empty interface (or an interface without any exported methods) is a very odd thing in Go. It gives users no way to discover the implementations by looking at the godoc. If I was not reading the source code, I'd have little or no clue that AggregationCount is implementing Aggregation.

My suggestion is to export the methods on interface, so implementations can live anywhere.

// Aggregation represents ....
type Aggregation interface {
	Value() func() AggregationValue
}

Then, the exporters can always switch type and do whatever for the types provided from the blessed packages.

Or we can make the interface depend on an internal symbol (example) not to allow anyone outside of the opencensus packages to implement the interface. But within the Census packages, we will have flexibility to organize stuff in multiple packages.

[acetechnologist]

type Aggregation interface {
Value() func() AggregationValue
}
Why export something that is not necessary or even useful? This function is only useful because of the implementation details I decided to go with. If tomorrow we decide to change the implementation details and don't need this function it will be easier if it is not exported.

Having the interface depend on an internal symbol is fine with me. It will allow the user to know which types are actually aggregations but I think the same can be achieved with documentation.

[rakyll]

Let's wait for the implementation details, and we can ask others to provide some more feedback/ideas. Anything can be fixed by docs but docs should always be the last resort.

[rakyll]

Won't fix because we need these types provide accessors to their fields and exporters will depend on them when uploading data.