Shared publicly  - 
 
+Daniel Spiewak Regarding your jbencoder [0]. Can't you make it simpler?

Can't you just accept Iterables in the decode and encode format? (As I see it, the whole point of bencode is to be so simple so that you wouldn't need a parser).

eg https://gist.github.com/1718032

Anyhow, nice framework, thanks for sharing it.

[0] http://www.codecommit.com/blog/java/bencode-stream-parsing-in-java
1
Daniel Spiewak's profile photoElazar Leibovich's profile photo
4 comments
 
So, that will work for sending value to output. It's extremely inconvenient if you're going in the other direction (parsing). Also, it's not particularly type safe with respect to what types can and cannot be serialized. Finally, the set of serializable types is closed (specifically by if/else statement with instanceof checks). I needed that set to be open for my original application.
 
First, thanks for responding!

Type safety - it's just an illusion, this could be type safe, you only need to emulate algebraic data types in Java (ByteArrayWrapper,ListWrapper<BencodeSerializable>,IntegerWrapper extends BencodeSerializable), I was being lazy. If else with instanceof checks is pattern matching in disguise.

Closed set - I see it as a good thing. Bencode encodes lists maps, integers or byte arrays. If you want to store anything in bencode - convert it to one of the bencode supported types. Why do you want to couple converting your data type to bencodable types with the bencode encoder?

Receiving values - I'm looking at it, I'll post my conclusions here. Anyhow in your code those are two independent code bases, so we can change one without affecting the other.
 
Type safety: Emulating algebraic data types is exactly what the Type hierarchy does. Well, it also ensures the set of types is open, but that is orthogonal to the type safety issue.

Open set: I guess it depends on exactly what your application is. We had need of a richer set of datatypes than what bencode offers. Without the ability to encode custom types, we would have need to dump a lot of things into strings, which is just…annoying.

Receiving types: You are correct that this hierarchy is independent, which is not a design that I like. I've never gone back to refactor the code, but it would certainly be possible to rectify this issue.
 
Type safety: What I didn't like in your design, is that the algebraic data types are coupled to the iteration functions. You must implement `populate` for this particular type. In my view those should be purely algebraic data types. ByteArrayWrapper should contain a single byte array, and that's all. No other methods.

Open set: I thought that you would like to separate the bencode encoder, and the system that encode your classes to bencode-objects, but your approach also makes sense. Sort-of like `extends SerializableToBencode`.
Add a comment...