ceylon.io: redesign Buffers

[gavinking]

I'm really not happy with the way Buffer, ByteBuffer and CharacterBuffer are modeled, or their relationship to Charset.Encoder/Charset.Decoder.

• CharacterBuffer has a bunch of unimplemented operations.
• It appears that some operations have subtly different semantics for readonly Buffers (this might just be misleading documentation, however).
• The abstract supertype Buffer doesn't really seem to add much.
• Decoders have an underlying StringBuffer, whereas Encoders accept a ByteBuffer and CharacterBuffer on every call, making Encoder and Decoder quite asymmetric.
• CharacterBuffer basically just wraps a String! Do we even need this thing? Why don't we just pass the damn String to the constructor of Encoder?
• Encoder and Decoder have a very fragile state model.

Overall this is just not a very satisfying design.

[gavinking]

I propose to eliminate most of this complexity, by deleting Buffer and CharacterBuffer from the API, since right now they're not really used for anything. That way, ByteBuffer will become a more cohesive thing.

[quintesse]

Not sure if it has to do with mirroring Java's NIO design where you can have buffers for all the primitive types: ByteBuffer, CharBuffer, DoubleBuffer, FloatBuffer, IntBuffer, LongBuffer, ShortBuffer. But the ByteBuffer (http://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffer.html) is basically the central one, from that one you can get the others as "views".

[gavinking]

Well NIO has all that, but we don't really.

And plus there is a performance problem with the design of Buffer, the generic get() method returns a boxed type.

[FroMage]

Encoder and Decoder are indeed asymmetric and I didn't like that at the time. They should both use buffers. In general, we should never use arrays for IO.

[gavinking]

@FroMage But your CharacterBuffer is a totally useless thing. It's just a wrapper for a String.

[FroMage]

Well, not at all, it's a character buffer. Like an array of characters with position/limit. It allows you to transfer characters to and from anything, without having to allocate strings.

[gavinking]

@FroMage No it doesn't. It's a wrapper for a String. You must have forgotten to finish writing that class, because the functionality you're describing has nothing to do with what the actual class actually does.

[FroMage]

You're right. I did not finish it. It's a buffer for reading from a String ATM. It should be similar to a byte buffer, and optionally allow for reading from a String read-only too (or its underlying character array if we can access it).

[gavinking]

Well IMO you need to either finish it or remove it because currently it's pretty hard to tell even what you're trying to get at with these APIs. I think I sorta understand where you want to go, but you're definitely not there yet.

[FroMage]

Well, obviously I've no time to finish it, and that's why I asked help from people who understand buffers. IO is a world in itself, and buffers seem to be a good abstraction to avoid allocation and copying. Much better than arrays or other things.

[FroMage]

ATM the StringBuffer is already more useful than a String because it allows you to read from a String in parts while pushing IO on the other end.

[FroMage]

Note that perhaps the buffer abstraction is a thing of the past and should be replaced by Iteratees or other fancy stuff. I doubt it, but who knows? Perhaps I'm wrong. I haven't really studied it.

[luolong]

Yeah, Iteratees are a neat way of handling IO.