Rename libserialize

[brson]

Since the types are called Encode and Decode, etc. it probably makes sense for the module to reflect this naming, maybe 'encoding' (or 'encodement' 👻 ). Yeah I argued the other way last time. Oh well.

[brson]

@erickt What do you think?

[graydon]

I'd be fine with this if we also clustered all the concrete encodings in (say) {std, extra}::encoding::* submodules, with a few standard ones like json and xdr, and others left to extra.

(mostly for discoverability)

[graydon]

Note that if you do this, there will be some collision with the need to define character encodings. I believe this was part of the rationale for the current approach. Character encoding has (I think?) a slightly stronger precedent for use of the term than serialization encodings.

[metajack]

visiting for triage. nominating for backward compat.

[catamorphism]

accepted for backwards-compatible

[nikomatsakis]

I prefer encode to encoding. I guess we should have a consistent pattern for naming modules, but for some silly reason gerund module names rubs be wrong.

[brson]

Since there's another proposed feature for encoding and decoding strings, it may be appropriate to switch back to serialization and deserialization as the terminology here.

[alexcrichton]

This has moved to libserialize, updating the title

[brson]

@erickt Do you have any new opinions on what we should do here?

[erickt]

@brson: I think using Serialize/Serializer/Deserialize/Deserializer would be easiest since that's what we've been calling these operations anyway.

[errordeveloper]

Well, I think calling it libcodecwould nice a short. I'd keep type names as they are, it's pretty good. Let's not rename for the sake of renaming. It's only the name of the library that was in question, the insides are good, I find.

[liigo]

Libcodec, +1
On Jul 8, 2014 7:00 AM, "Ilya Dmitrichenko" notifications@github.com
wrote:

Well, I think calling it libcodecwould nice a short. I'd keep type names
as they are, it's pretty good. Let's not rename for the sake of renaming.
It's only the name of the library that was in question, the insides are
good, I find.

—
Reply to this email directly or view it on GitHub
#7098 (comment).

[brson]

I would not assume that something called libcodec is a serialization library, but a media decoding library.

[brson]

Of course the same is true of encode.

[brson]

@erickt If I wanted to rename the Encode/Decode types, and others containing those words, leaving the deprecated originals in place, would it be better to do it now, or wait until you've got your redesign finished?

[erickt]

I'd wait for my redesign. I've finally finished the core of my work, now I'm validating the design by porting toml/msgpack/mustache/etc over to it to validate the design. So hopefully it won't be too long until I'm ready to merge it upstream.

[brson]

Nominating for removal from 1.0. If the naming in this lib ends up inconsistent it's not the end of the world (of Rust). The entire lib could also just be experimental for 1.0.

[aturon]

FWIW, I think it is unlikely that we'll be able to stabilize this library for 1.0, despite it's importance -- especially with significant new design work coming down the pike.

[pnkfelix]

removing from 1.0 milestone and reassigning as P-low.

[aturon]

This is no longer relevant with the move of the crate into crates.io.