Make IO a class

[asterite]

This changes IO to be a class instead of a module. The reasons are:

1. IO has an @encoding variable that can be set and changed. This makes IO as a struct very inconvenient because its mutable.
2. There are no struct IOs in the standard library.
3. Less code is generated (code for module dispatch is huge and repeats in every method call). This point can probably be improved by improving the compiler, but the other two points are still relevant.

Because Zip::File now works with IO instead of a union of two specific IOs (and this can't be represented in the language because the types get merged to the closest ancestor) I added raising methods like seek and pos, which also make sense because all IOs should provide that interface, even if they can't effectively implement it (otherwise, let's break IO into many small interfaces like in Go, that's acceptable too but a much bigger and boring change).

[RX14]

I was about to PR creating a Crystal::System::FileHandle class which will conflict with this. Some coordination between the two will be required as I changed the semantic of seek to return the absolute offset and improved the docs. Is removing tell a good idea, as an alias of pos?

[RX14]

Making seek return the new position has the advantage of allowing you to implement pos and pos= entirely in terms of seek, which means inheriting classes only need to implement seek.

[asterite]

Yes, I think we can remove tell

[asterite]

(I'll leave it in this PR, though)

[bcardiff]

I can't think of an example where a class IO won't work and a module would be better. Yet I always liked that acting as an IO didn't require a base class.

It's hard to search "include IO" in all crystal repositories in github, from a wider search there are many occurrences that can be found. There are some usages in db drivers.

Would it be to much of a burden to:

• in vNext

  1. declare IO::Base abstract class
  2. make IO print a deprecation warning

• in vNext+1

  1. remove module IO
  2. change IO::Base to IO
  3. make IO::Base < IO with a deprecation warning

• in vNext + 2

  1. remove IO::Base

Probably yes. The error will be point easily. But without that there is a hard dependency requirement for shards and compiler version IMO.

[bcardiff]

shouldn't the delimiter be interpreted in the encoding of the underling io?

[asterite]

Maybe, but we can discuss that in a separate PR :-)

[bcardiff]

WhyIO::Buffered should be a module and IO::Delimited a class?

[asterite]

We could make IO::Buffered a class too, but then you'd have to do like in Java:

io = File.open("some_file")
io = IO::Buffered.new(io)
io.gets

otherwise things will be very inefficient. That's why in Ruby buffering is embedded in these kind of IOs because it's almost always slow otherwise.

We could have IO::Buffering as a module and IO::Buffered as a class, though, or something like that.

Still, maybe a discussion for another issue :-)

[asterite]

@bcardiff I don't know about those steps. Maybe it's better to just break things, given that the fix is really simple. This will make shards that depend on other shards break and people filling PRs to fix this.

[asterite]

Bump!

[asterite]

Oh, this is actually approved. I'll use the "If a crystal-lang org member creates a PR, at least one other member has to approve it" card here ♣️