You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the storage API only allows for String types to be added. On a java
platform this requires casting between primitive types when retrieving values
which tends to make loading from storage an ugly chunk of code.
This API should be improved to include automatic support for saving/loading
primitive java types and possibly Serializable types.
Original issue reported on code.google.com by [email protected] on 3 Jun 2011 at 1:19
The text was updated successfully, but these errors were encountered:
When you say "primitive" java types, do you mean literal primitives (i.e., Java
value types like int, string, short, etc), or Java object types? The former
would be a trivial change, but the latter is a *big* can of worms, as you're
indirectly asking for full string serialization of Java object graphs.
This can be awkward enough when running on a "real" JVM (e.g., you have to deal
with subtle changes to the structure of the object graph when upgrading the
app), but it's much worse when compiled to Javascript/AS3, because we don't
have reflection there. In GWT-land, there have been numerous attempts to solve
this problem, but they all get hairy quickly because of the amount of code you
have to generate to serialize arbitrary object graphs (not to mention that
statically computing the set of types that might need to be serialized is
Turing-complete in the general case).
I don't mean to diminish the importance of the use-case -- this comes up not
just in Storage, but generally in network communications. But I think it makes
sense to consider alternative, restricted, serialization forms, like protocol
buffers, thrift, json+schema. Perhaps we'll need to add a little code
generation to the mix to make it tolerable.
By primitive I mean literal primitive which is the main thing I'm after. The
serialization is more of a nice to have if possible and not too complicated
kind of request.
I didn't think about that case of dealing with class structure changes and was
in fact thinking more in terms of restricted serialization forms like json
especially for javascript. I can see cases that might come up where it would be
nice to dump a settings object to storage in 1 call rather than writing
read/write calls for every variable.
Since the serialization problems require more thought forget about that for
now, primitives are enough.
Original issue reported on code.google.com by
[email protected]
on 3 Jun 2011 at 1:19The text was updated successfully, but these errors were encountered: