Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

encoding/asn1: inconsistent APIs #1133

Closed
gopherbot opened this issue Sep 23, 2010 · 5 comments
Closed

encoding/asn1: inconsistent APIs #1133

gopherbot opened this issue Sep 23, 2010 · 5 comments

Comments

@gopherbot
Copy link

by jan.newmarch:

Which revision are you using?  (hg identify)
6d3022dfb42b tip

Several packages in Go involve serialisation: gob, asn1, json. But they have mutually
inconsistent APIs, which could cause programmer errors down the track. Still time to fix
them?

1)
json: func Marshal(v interface{}) ([]byte, os.Error)
asn1: func MarshalToMemory(val interface{}) ([]byte, os.Error)
gob: no function

json and asn1 have different names for same functionality, missing in gob.

2)
asn1: func Marshal(out io.Writer, val interface{}) os.Error
json: no equivalent
gob: no equivalent

Note same name but different parameter and return types for asn1.Marshal compared to
json.Marshal

3)
asn1: func Unmarshal(val interface{}, b []byte) (rest []byte, err os.Error)
json: func Unmarshal(data []byte, v interface{}) os.Error

Parameters are swapped, result is different.

4)
json and gob have Decoder and Encoder, asn1 doesn't
json: func NewDecoder(r io.Reader) *Decoder
gob: func NewDecoder(r io.Reader) *Decoder
asn1: none

5)
json: func (dec *Decoder) Decode(v interface{}) os.Error
gob: func (dec *Decoder) Decode(e interface{}) os.Error
asn1: none

Summary:
gob and json are almost identical, except json has additional Marshal/Unmarshal
functions.
asn1 is clearly at variance to both the others.

XML could also be considered a serialisation technique, but that is even more variant.
This is perhaps excusable, but then again maybe not.
@gopherbot
Copy link
Author

Comment 1 by akidan:

A nice side effect of making these more consistent is that it becomes simple for anyone
to declare a common interface for marshaling/unmarshaling if desired (analogous to
io.Reader/io.Writer) and be able to swap in json, gob, asn1 or another format as needed.

@robpike
Copy link
Contributor

robpike commented Sep 24, 2010

Comment 2:

Gobs can't implement marshal and unmarshal in the raw the way JSON and ASN1 can because,
unlike JSON and ASN1, there is type information stored in the data.  It's a stream
protocol, not a packet protocol.  There could be a variant that always includes the type
information but that would be wasteful and could lead to bad programming.

@gopherbot
Copy link
Author

Comment 3 by akidan:

That makes sense.  
However, what about the opposite - that JSON and ASN1 could also be expressed as
streams, like gobs?

@rsc
Copy link
Contributor

rsc commented Sep 24, 2010

Comment 4:

Rob points out that gob only makes sense in stream mode.
Json has a stream mode that matches the gob one exactly
(read the docs for Encoder and Decoder in those packages).
ASN.1 is not general enough to expend effort on things
like streams.  It's such an awful format.  The only reason
anyone takes it seriously is you have to use it to decode
SSL certificates, and that's all the package is intended for.
JSON and ASN.1 are different too: ASN.1 is good at binary
blobs of data while that's arguably JSON's one weakness.
Even so, I think you're right that it would be good to use
the same signature for Marshal and Unmarshal in both,
if only to set a good precedent for future packages.
I'll update package asn1.

Owner changed to r...@golang.org.

Status changed to Started.

@rsc
Copy link
Contributor

rsc commented Sep 24, 2010

Comment 5:

This issue was closed by revision 8206baf.

Status changed to Fixed.

@mikioh mikioh changed the title asn1, gob and json have inconsistent APIs encoding/asn1: inconsistent APIs Feb 26, 2015
@golang golang locked and limited conversation to collaborators Jun 24, 2016
@rsc rsc removed their assignment Jun 22, 2022
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants