Skip to content
This repository has been archived by the owner on Jun 22, 2021. It is now read-only.

Formatting for typedefs #142

Open
rooftopsparrow opened this issue Nov 7, 2016 · 1 comment
Open

Formatting for typedefs #142

rooftopsparrow opened this issue Nov 7, 2016 · 1 comment

Comments

@rooftopsparrow
Copy link

rooftopsparrow commented Nov 7, 2016

Hello thriftrw!

I was curious if there was a way to apply formatting to a particular typedef or field definition globally?

For example, if we have a thrift typedef:

typedef IPAddress list<byte>

struct Connection {
  1: IPAddress host,
  2: i32 port
}

that 90% of the time we would want displayed as an IP address string.

Ideally, there would be a way to read from a thrift buffer then convert ( optionally ) to a formatted JS object. Also, it would be great to define the inverse as well; go from a formatted field to the raw type definition.

thrift.Connection.fromFormatted({ host: '127.0.0.1', port: 1234 }) // => Connection { host: [ 127, 0, 0, 1 ], port: 1234 }
thrift.Connection.fromBuffer(buffer).toFormatted() // { host: '127.0.0.1', port: 1234 })

If this is something that doesn't exist I'd be very interested in contributing. Thanks!

@kriskowal
Copy link
Contributor

Something similar could be supported with an annotation like (js.type = 'ipv4-string') with the implication that the type would be able to coerce strings containing ipv4 addresses when encoding, and prefer the string representation when decoding. Alternately there could be a (js.type = 'AddressObject') that would do the same for an AddressObject type that would resemble your {host,port} representation. The pattern exists for i64 alternate representations. On the wire, i32 would always be a four byte signed number, but you can use the annotation to control the code representation.

In general though, it would be preferable I think to perform the conversion in your handler.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants