Should Buffer/JSonObject have BigDecimal, BigXXXX Support

[bytor99999]

Since we deal with money in our application, we specifically use BigDecimal as it is the only class that you can best rely on for money applications, and also the only class that the Gaming License Labs will approve. Meaning, unless you use BigDecimal, you ain't able to put it in a gambling machine in Las Vegas. 

But Buffer doesn't support that type and throws an exception when it tries to wrap/unwrap it.

Thanks

Mark

[Henryk Konsek]

Hi Mark,

You can always convert your BigDecimal money values to integer "pennies" before sending it over the event bus. I guess that for USD you won't have precision bigger than two decimal points, so this kind if (de)serialization should be easy and safe.

Cheers! 

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/77395e29-37f6-4557-8287-a91d0759f960%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brane F. Gračnar]

On Tuesday, July 28, 2015 at 5:03:34 AM UTC+2, bytor99999 wrote:

Since we deal with money in our application, we specifically use BigDecimal as it is the only class that you can best rely on for money applications, and also the only class that the Gaming License Labs will approve. Meaning, unless you use BigDecimal, you ain't able to put it in a gambling machine in Las Vegas. 

But Buffer doesn't support that type and throws an exception when it tries to wrap/unwrap it.

Just use BigDecimal's toString(), send it as string over event bus, on the other side reconstruct it with new BigDecimal(String) constructor.

Best regards, Brane

[bytor99999]

We do use longs in the free to play game. But the whole thing is having to make sure anywhere we now have BigDecimal and convert it. Instead of just letting it stay in our code and it work with Buffer. ;)

But thanks.

Mark

[Paulo Lopes]

JsonObject/JsonArray do not accept BigDecimal/BigInteger mostly because of interop with other systems. Browsers running ECMAScript for example cannot deal with the full range of 64 bit integers (their limit being all integers with a magnitude of 2^53 or less).

If we look at BigInteger javadoc it says something like: "Immutable arbitrary-precision integers" with this in mind we could encode them to json (it is totally accepted by the spec) but probably this data can only be consumed by a java json parser or probably by the same library that encoded it initially. The same rationale would apply for BigDecimal.

As said before, for maximum interop i'd recommend to encode to String and then on the other end parse the string back to BigDecimal/BigInteger...

[bytor99999]

Vert.x 2.x worked with BigDecimal.

Mark

[foxgem]

+1

In Groovy, the default type of number like 0.1 is BigDecimal.

When my project is ported to vertx3, I hit the same issue and have to write a converter to transform those numbers to float mannually when I put them onto eventbus.

Those code works under vertx 2.1.5, I really would like to see BigDecimal will be supported in vertx3.

-- 

foxgem

已使用 Sparrow

已使用 Sparrow

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/b3d57251-04ce-4d0f-a626-86548880828d%40googlegroups.com.

[Kamil Becmer]

Are you guys serious? There are a number of services you can't say "hey slice your money to pennies, because my super-duper json implementation are unable to handle that big thing".

Firstly: JSON spec doesn't limit numerals in size.

Secondly: in Java you have BigDecimal and BigInteger (don't forget about it)

Thirdly: What the heck ECMAScript has to do with numbers outside JS-world? Don't limit everyone else because limits of one platform.

I could understand if this problem was a matter of TODO, but you ignored this issue in 2015. Now is 2017, i'm going to write some "why vertx gives a duck" posts to warn others about this abnormal ignorancy.

[Jochen Mader]

I'd suggest you grab a drink and chill out a little.

Paulo gave a pretty valid reasoning that goes way beyond "igorance".

The primary JS-target of Vert.x is ECMA. That's because we:

- have an eventbus interacting with the browser

- most things people build using vertx-web will have a browser interact with it

- follow the standard, which is *ohgosh* defined by ECMA

Vert.x is also polyglot, so we have to take such cross-language-problems into account where one datatype will cause issues in another language.

Doing the suggested yaddayadda would introduce hard to debug issues on the browser side which, in the year 2017, is the primary target of most applications.

If this is a problem to you then you can follow one of the suggested alternatives or add a custom encoding.

--

You received this message because you are subscribed to the Google Groups "vert.x" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/8d6749da-aabd-4d7b-a79e-8585c6df5283%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Jochen Mader | Principal IT Consultant

codecentric AG | Elsenheimerstr. 55a | 80687 München | Deutschland
tel: +49 89 215486633 | fax: +49 89 215486699 | mobil: +49 152 51862390
www.codecentric.de | blog.codecentric.de | www.meettheexperts.de

Sitz der Gesellschaft: Düsseldorf | HRB 63043 | Amtsgericht Düsseldorf
Vorstand: Michael Hochgürtel . Rainer Vehns
Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen Schütz

[Julien Viet]

perhaps this use case should be captured in the cookbook ?

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CAAn-prVXoVytp3P6TaiSnjuGO-BH%3DheaX6Yd_mV%2BXU9rE_RiiQ%40mail.gmail.com.

[ad...@cs.miami.edu]

>> If this is a problem to you then you can follow one of the suggested alternatives or add a custom encoding.

custom encoding seems pretty practical. 

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/8d6749da-aabd-4d7b-a79e-8585c6df5283%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Jochen Mader | Principal IT Consultant

codecentric AG | Elsenheimerstr. 55a | 80687 München | Deutschland
tel: +49 89 215486633 | fax: +49 89 215486699 | mobil: +49 152 51862390
www.codecentric.de | blog.codecentric.de | www.meettheexperts.de

Sitz der Gesellschaft: Düsseldorf | HRB 63043 | Amtsgericht Düsseldorf
Vorstand: Michael Hochgürtel . Rainer Vehns
Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen Schütz

[Jez P]

But go ahead and write the blog posts, they'll show more about your ignorance than any fundamental problem with the vert.x project. 

On Monday, July 3, 2017 at 8:28:35 AM UTC+1, Jochen Mader wrote:

I'd suggest you grab a drink and chill out a little.

Paulo gave a pretty valid reasoning that goes way beyond "igorance".

The primary JS-target of Vert.x is ECMA. That's because we:

- have an eventbus interacting with the browser

- most things people build using vertx-web will have a browser interact with it

- follow the standard, which is *ohgosh* defined by ECMA

Vert.x is also polyglot, so we have to take such cross-language-problems into account where one datatype will cause issues in another language.

Doing the suggested yaddayadda would introduce hard to debug issues on the browser side which, in the year 2017, is the primary target of most applications.

If this is a problem to you then you can follow one of the suggested alternatives or add a custom encoding.

2017-07-01 23:57 GMT+02:00 Kamil Becmer <kamil....@gmail.com>:

Are you guys serious? There are a number of services you can't say "hey slice your money to pennies, because my super-duper json implementation are unable to handle that big thing".

Firstly: JSON spec doesn't limit numerals in size.

Secondly: in Java you have BigDecimal and BigInteger (don't forget about it)

Thirdly: What the heck ECMAScript has to do with numbers outside JS-world? Don't limit everyone else because limits of one platform.

I could understand if this problem was a matter of TODO, but you ignored this issue in 2015. Now is 2017, i'm going to write some "why vertx gives a duck" posts to warn others about this abnormal ignorancy.

W dniu wtorek, 28 lipca 2015 05:03:34 UTC+2 użytkownik bytor99999 napisał:

Since we deal with money in our application, we specifically use BigDecimal as it is the only class that you can best rely on for money applications, and also the only class that the Gaming License Labs will approve. Meaning, unless you use BigDecimal, you ain't able to put it in a gambling machine in Las Vegas. 

But Buffer doesn't support that type and throws an exception when it tries to wrap/unwrap it.

Thanks

Mark

--
You received this message because you are subscribed to the Google Groups "vert.x" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/8d6749da-aabd-4d7b-a79e-8585c6df5283%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.