I need to encode/transfer Cardinal and Qword values, which is currently not possible
(at least for qwords) therefor i wanted to extend fpjson with support for that number types
and provide a patch.
bad idea ? / objections ?
thx,
helmut
Mailing lists / fpc-devel / 2014-04
extend fpjson with support for cardinal/qword
4 messages · 2 people ·
- Helmut Hartl 2
- Michael Van Canneyt 2
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
Helmut Hartl wroteI need to encode/transfer Cardinal and Qword values, which is currently not possible (at least for qwords) therefor i wanted to extend fpjson with support for that number types and provide a patch.
1. Cardinal should already be possible if you simply use Int64 to transfer them. There will be no type checking, but that is not a problem, we're talking Javascript subset here...
2. Qword: we should check whether Javascript supports this range of value. If so, a patch would be accepted.
Michael.
Michael Van Canneyt wrote 5 lines
....
1. Cardinal should already be possible if you simply use Int64 to
transfer them.
There will be no type checking, but that is not a problem, we're
talking Javascript subset here...
Yes.
2. Qword: we should check whether Javascript supports this range of value. If so, a patch would be accepted.
Javascript (standard) internally uses doubleprecision floating points (http://ecma262-5.com/ELS5_HTML.htm#Section_8.5)
to represent it's numbers so to some extent it's possible to represent that numbers, although arithmetic would behave
strange in that ranges :-)
JS is only a subset of my usecase - I want to store such values in a text representation as a backup format for our
database server, and do not want to use a string representation. I'll send you a patch against current trunk when ready, so you can have a look.
thx,
helmut
Helmut Hartl wrote 20 lines
Am 16.04.14 12:06, schrieb Michael Van Canneyt:
....
1. Cardinal should already be possible if you simply use Int64 to transfer them.
There will be no type checking, but that is not a problem, we're talking Javascript
subset here...
Yes.
2. Qword: we should check whether Javascript supports this range of value.
If so, a patch would be accepted.
Javascript (standard) internally uses doubleprecision floating points
(http://ecma262-5.com/ELS5_HTML.htm#Section_8.5)
to represent it's numbers so to some extent it's possible to represent that numbers, although
arithmetic would behave
strange in that ranges :-)
JS is only a subset of my usecase - I want to store such values in a text representation as a
backup format for our
database server, and do not want to use a string representation.
I'll send you a patch against current trunk when ready, so you can have a look.
Great, I'll be waiting for it !
Michael.