FW: Problem with deserializing large ints on Flash9

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

FW: Problem with deserializing large ints on Flash9

Michael Pliskin
Yes your solution will definitely work for Flash-JS, you're right, and it
will break for flash-neko. Date type is a solution, but why don't you like
my another approach with unserializer detecting overflow automatically and
preventing it?

Mike

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Nicolas Cannasse
Sent: Friday, October 24, 2008 12:14 PM
To: The haXe compiler list
Subject: Re: [haXe] Problem with deserializing large ints on Flash9

Michael Pliskin a écrit :
> Yes I will have to use float for that, BUT even if I send smth as Float
from
> Flash8, it will be encoded as Int when serializing! So there is no way
then
> to send large numbers from flash/js at all! That's the problem I think.

For Flash/JS, I think that the proposed fix in Type.typeof should work.
As for Flash8->Neko or JS->Neko, you're right there's still a problem
when an integer which would be in-range in Flash but out-range in Neko.
That's a typical overflow.

The only possibility I can see is a bit a hack, since it consists to add
0.1 to your Flash number in order to force the float serialization.

Please note also that Serializer natively supports Date type, which
would maybe be much more easy for you to use.

Best,
Nicolas


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: FW: Problem with deserializing large ints on Flash9

Nicolas Cannasse
Michael Pliskin a écrit :
> Yes your solution will definitely work for Flash-JS, you're right, and it
> will break for flash-neko. Date type is a solution, but why don't you like
> my another approach with unserializer detecting overflow automatically and
> preventing it?
>
> Mike

I think that types should be accurate in serialization : if you
serialize an Int, you should get an Int on the other side. The fact that
an overflow occurs is a platform-specific problem, and the correct way
to deal with it is to serialize a float, not to transform the int into a
float at unserialization time. At least that's my opinion so far.

Best,
Nicolas

--
haXe - an open source web programming language
http://haxe.org