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

String names in codecs #15

Closed
tonymorris opened this issue Dec 30, 2012 · 6 comments
Closed

String names in codecs #15

tonymorris opened this issue Dec 30, 2012 · 6 comments

Comments

@tonymorris
Copy link
Member

The String name in EncodeJson and DecodeResult are an extremely bad idea. They need to disappear.

@ghost ghost assigned seanparsons Dec 30, 2012
@seanparsons
Copy link
Member

Do you mean changing:

val result: (String, CursorHistory) \/ A

to

 val result: CursorHistory \/ A

?

If so I think I've got this done, surprising how much I've had to change.

@markhibberd
Copy link
Contributor

Absolutely agree with EncodeJson - been trying to.convince you of that for ages.

Absolutely disagree with DecodeResult loses information if there is no replacement mechanism.

@seanparsons
Copy link
Member

I'm much less convinced of the change to DecodeResult than I am of the EncodeJson/DecodeJson name.

@tonymorris
Copy link
Member Author

Modelling this in haskell makes it pretty obviously a mistake in both cases. The better (replacement) behaviour is to change the type of the value kept in history, which may include "the decoder name." Of course, this should all be polymorphic to emphasise that point.

Haskell is nearly complete. Stand-by.

@markhibberd
Copy link
Contributor

On Dec 31, 2012 12:04 PM, "tonymorris" [email protected] wrote:

Modelling this in haskell makes it pretty obviously a mistake in both
cases. The better (replacement) behaviour is to change the type of the
value kept in history, which may include "the decoder name." Of course,
this should all be polymorphic to emphasise that point.

Nope. Loses information. The codec name is not the important thing. There
are two types of decode failure: structural (captured by cursor history)
and semantic (currently smashed into that string). I am not suggesting that
the string is a good idea to capture this, but what you are describing is
not correct. Need to look at something else to capture this.

Haskell is nearly complete. Stand-by.


Reply to this email directly or view it on GitHub.

@tonymorris
Copy link
Member Author

You're right. I think the String part sticks out as fugly especially because it is a String. Pairing any other value looks fine.

The encoder is where the more obvious improvements were made by removal of the String. Perhaps only that should be removed and leave the decoder as is as a separate issue (i.e. String iz suckz).

tonymorris added a commit to tonymorris/argonaut that referenced this issue Dec 31, 2012
…and added a couple more library functions to EncodeJson
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

No branches or pull requests

3 participants