Holding dynamic variables in a statically-typed language

7 views
Skip to first unread message

Johannes Klug

unread,
Mar 30, 2012, 10:30:50 AM3/30/12
to humming...@googlegroups.com
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

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

Johannes Klug

unread,
Mar 30, 2012, 12:01:39 PM3/30/12
to humming...@googlegroups.com
Am 2012-03-30 16:30, schrieb Johannes Klug:
> Now, have a look at MessagePack's "Value" class:
>
> http://msgpack.org/javadoc/current/org/msgpack/type/class-use/Value.html

Another alternative could also be BSON, which MongoDB uses internally:
http://bsonspec.org/

Gert Villemos

unread,
Apr 2, 2012, 4:14:21 AM4/2/12
to humming...@googlegroups.com
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

Johannes Klug

unread,
Apr 2, 2012, 4:37:02 AM4/2/12
to humming...@googlegroups.com
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>
> 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

Mark Doyle

unread,
Apr 2, 2012, 6:13:17 AM4/2/12
to humming...@googlegroups.com
Let's talk about this in detail. I'm wary of refactoring something that is well tested and works, just for API reasons when there is so much to do elsewhere. We can always clean up the API later, say when we have some applications, some guis, a full chain for strand, the ground station etc

Having said that I think it looks, on the surface, like a good idea, and I can see the benefits of doing it now rather than later in that it won't affect applications. Experiment on another branch?

On 2 April 2012 10:37, Johannes Klug <j...@jklug.com> wrote:
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>
Reply all
Reply to author
Forward
0 new messages