Skip to content

Conversation

@thomasvl
Copy link
Collaborator

Gives developers a way to tell something is there, even if we
don't really have help for parsing it.


public struct UnknownStorage: Equatable {
internal var data = Data()
public private(set) var data = Data()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

internal(set)? (Sorry, didn't realize it was originally internal, not private, when we chatted offline.)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm gonna go with private for the moment because we don't actually want to force set the data, it should be always coming in via append()

Gives developers a way to tell something is there, even if we
don't really have help for parsing it.
@thomasvl thomasvl force-pushed the expose_unknown_data branch from 5ae36a5 to d04b6a9 Compare February 28, 2017 17:56
@thomasvl
Copy link
Collaborator Author

Update tests where I was looking at unknowns to be much simpler by using this.

Copy link
Collaborator

@tbkka tbkka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@tbkka
Copy link
Collaborator

tbkka commented Feb 28, 2017

This is a good change: Data is the right type to expose here, it makes perfect sense to share a "raw" version of this with our clients, and we do want it to be read-only.

@thomasvl thomasvl merged commit f157da7 into apple:master Feb 28, 2017
@thomasvl thomasvl deleted the expose_unknown_data branch February 28, 2017 18:09
@allevato
Copy link
Collaborator

Data is the right type to expose here

For now, maybe—but we eventually want a way for users to look at the field numbers and wire-format values individually like the other languages allow. But with the implementation we have now, exposing the data is better than exposing nothing, since building that other API would take longer and I don't think we need it for 1.0.

@tbkka
Copy link
Collaborator

tbkka commented Feb 28, 2017

...we eventually want a way for users to look at the field numbers and wire-format values individually like the other languages allow

Absolutely. Constructing such a view does carry a CPU and memory cost, of course, so I would prefer to make that explicit and not construct such a view until the user actually asks for it. The Data form is efficient and compact for cases where users don't ever need to directly access individual unknown fields.

@allevato
Copy link
Collaborator

Yep, building the smart view lazily for the user should be trivial.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants