last night, I had another look at MessagePack. I was curious how others
dealt with variables whose type is unknown at runtime, in particular in
their Java API. As you know, this was one of the tougher bits we had to
solve in Hummingbird, and it was made even tougher than it should be by
the way Java handles generics (type erasure, and so forth).
Now, have a look at MessagePack's "Value" class:
http://msgpack.org/javadoc/current/org/msgpack/type/class-use/Value.html
It might do what our Parameter class does, plus it's not typed, but
encapsulates the actual value. That would simplify our API enormously:
No more getAllInts(), getAllFloats() etc. We could potentially re-use
this class in favour of our Parameter<T>, and reduce our code by a few
chunks. What do you think?
Cheers,
Johannes
Another alternative could also be BSON, which MongoDB uses internally:
http://bsonspec.org/
One issue I see is that we'd be relying on one specific, rather
internal class. It might be safer to use the proper MessagePack API, so
our code won't break if they make internal changes.
Am 2012-04-02 10:14, schrieb Gert Villemos:
> The class looks good. It doesnt support every possible type, but
> likely we dont need that anyway. Lets go for it.
>
> Cheers,
> G.
>
> -------------------------
> VON: Johannes Klug <j...@jklug.com>
> AN: humming...@googlegroups.com
> GESENDET: 16:30 Freitag, 30.März 2012
> BETREFF: Holding dynamic variables in a statically-typed language
>
> Dear developers,
>
> last night, I had another look at MessagePack. I was curious how
> others dealt with variables whose type is unknown at runtime, in
> particular in their Java API. As you know, this was one of the
> tougher
> bits we had to solve in Hummingbird, and it was made even tougher
> than
> it should be by the way Java handles generics (type erasure, and so
> forth).
>
> Now, have a look at MessagePack's "Value" class:
>
> http://msgpack.org/javadoc/current/org/msgpack/type/class-use/Value.html
> [1]
>
> It might do what our Parameter class does, plus it's not typed, but
> encapsulates the actual value. That would simplify our API
> enormously:
> No more getAllInts(), getAllFloats() etc. We could potentially re-use
> this class in favour of our Parameter<T>, and reduce our code by a
> few
> chunks. What do you think?
>
> Cheers,
> Johannes
>
>
>
> Links:
> ------
> [1]
> http://msgpack.org/javadoc/current/org/msgpack/type/class-use/Value.html
Thanks for reviewing it, Gert!
One issue I see is that we'd be relying on one specific, rather internal class. It might be safer to use the proper MessagePack API, so our code won't break if they make internal changes.
Am 2012-04-02 10:14, schrieb Gert Villemos:
The class looks good. It doesnt support every possible type, but-------------------------
likely we dont need that anyway. Lets go for it.
Cheers,
G.
VON: Johannes Klug <j...@jklug.com>