Rename some public APIs regarding serialization/parsing.

[allevato]

This diverges slightly from the names already discussed in #12, after some more discussion with @thomasvl. A brief summary:

• Binary serialization is handled by serializedData() and init(serializedData: ...). I was less crazy about having "serialized" in the initializer label name, but as we'll see below with the text-based formats, this provides a consistency between the encoding function name and the parsing initializer's label that makes it very clear which APIs go together.

• Text format serialization is handled by textFormatString() and init(textFormatString: ...). String is part of the name because it clarifies the type of the argument (and makes it possible to introduce UTF-8 Data variants later). "Text format" is the official name of the format in protobuf land, so we use it instead of just "text".

• JSON serialization is handled by jsonString() and init(jsonString:). There's also init(jsonUTF8Data:), and anyJSONString() for that specific use case.

• unknown becomes unknownFields.

• Some other minor tweaks, like decodeTextFormat instead of decodeText and decodeBinary instead of decodeProtobuf on Message helper methods.

I want to make another pass through some of the internal helpers and change Protobuf to Binary, or possibly Coded, where it refers to the binary encoding. Protobuf sounds more like it's referring to the runtime in general and not specifically to the binary encoding—none of the other implementations use protobuf to mean that, whereas binary/coded would align nicely with those.

Makes progress on #12.

[thomasvl]

Names work for me, should we eventually rename a few of the files (ProtobufDecoder.swift, TextDecoder, etc.)?

[allevato]

Yes, I can do that when I rename the types.

…

On Thu, Feb 16, 2017 at 1:37 PM Thomas Van Lenten ***@***.***> wrote: ***@***.**** approved this pull request. Names work for me, should we eventually rename a few of the files (ProtobufDecoder.swift, TextDecoder, etc.)? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#276 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABA2G5YR1tNA2JUlzMF3c6UE1AHijPpmks5rdMGjgaJpZM4MDkGz> .

[tbkka]

I'm fine with those names.

[allevato]

I'm going to have to work on getting this merged tomorrow. I pulled some of the changes that @thomasvl made since I started on it, had to update ReservedWords to handle unknownFields and... now compiling unittest_swift_names.pb.swift makes the compiler segfault at a seemingly arbitrary location 😞

[allevato]

Tracked down the problem—unknownFields was being used as both a nested message struct name and the field name in the same parent message. Adding it to reserved words for type names fixed the problem. (Going to see if I can repro it in isolation since it's a compiler bug.)