Rename AbstractIOBuffer, it's not an abstract type

[tkelman]

rename AbstractIOBuffer to IOBufferBase
ref discussion at #11554 (comment)

Luckily very little code in base and no code in registered packages is using the constructor
for this type, only in dispatch (or in precompile calls) so this change should in theory not
be very noticeable. After we branch for release-0.5 we should consider removing the
parameterization and just call the type IOBuffer, since it doesn't look like anyone ever
uses any other type for the data field.

[vtjnash]

-1 The code isn't parameterized to handle this correctly. This seems to be code churn with no benefit.

[tkelman]

The benefit is the current AbstractIOBuffer isn't an abstract type at all. That's just silly, and actively confusing, naming. We could @deprecate_binding AbstractIOBuffer GeneralIOBuffer if you'd prefer that.

(osx travis failure was a seemingly unrelated freeze, log backed up to https://gist.github.com/080189cb8f707e08c404d4a57f927fad and restarted)

[TotalVerb]

Can't this be called IOBuffer? The constructor can be made to default to Vector{UInt8}. The only thing that should break are functions specialized on IOBuffer that suddenly accept all kinds of IOBuffer{T}s, which isn't necessarily a bad thing.

[tkelman]

I suspect it could but I wasn't sure exactly what that would look like.

[tkelman]

Suggestions? This seemed the least disruptive immediate resolution of the misleading naming. @stevengj you had some thoughts in february?

[vtjnash]

If you just don't want the name, the most correct change IMO would be just s/AbstractIOBuffer/IOBufferBase/g

Definitely don't add an actual abstract type. That's completely wrong (the abstract type interface this implements is IO. The type itself is abstracting over the storage backing, not the interface.).

FWIW, it's probably wrong to call AbstractIOBuffer a concrete type. In the part of our manual that introduce parametric types, it is called an abstract type: What does Point by itself mean? It is an abstract type... (http://docs.julialang.org/en/release-0.4/manual/types/#parametric-composite-types)

[tkelman]

We should probably be more distinct in our wording then, since abstract is a keyword we should avoid using that term elsewhere. I'd say something like "parameterized type family". I'll modify this to be a @deprecate_binding rename to IOBufferBase then.

[vtjnash]

Even more confusingly, from talking with carnaval, abstract IO is probably actually describing a concrete type from the type-system standpoint, since it has no unbound type-parameters. Thus, if we allowed construction of non-leaf types, it might be a candidate for being an instantiatable type (cross-ref #17086 discussion as well)

[stevengj]

Because the abstract parametric type shares the same name with the concrete parametric type for a given T, the usual Julia convention is to not use the name AbstractFoo in that case, and it is weird to make an exception here. (We don't say AbstractComplex even though, by that definition, Complex is an abstract type.)

I tend to favor just calling this IOBuffer, as @TotalVerb suggests, and seeing where the cards fall.

[tkelman]

Complex.abstract is false though so I don't think that's the best terminology to use for unbound parameters.

[tkelman]

I also like the sound of just calling the parameterized version IOBuffer but I'm not positive what the patch to do that correctly would look like.

[ggggggggg]

I just looked at iobuffer.jl to figure out how to implement IO and was very confused by the name AbstractIOBuffer for a few minutes. I support this change, or even changing it to IOBuffer, though I understand from the thread that that is harder. I think there is benefit in changing the name to make the code easier to read.

[StefanKarpinski]

The fact that AbstractIOBuffer is not an abstract type is totally ridiculous and must be fixed by 1.0.

[StefanKarpinski]

Resolved: renaming it to GenericIOBuffer.