Well, those need the ‘Abstract’ prefix to distinguish them from their concrete counterpart. There was already “Array” in the language, so what are you gong to call the type that is array-like but not literally an array?
But take another common - there is the abstract type “IO", who subtypes include IOStream and IOBuffer. There isn’t a need for “AbstractIO” because there is no “ConcreteIO” to disambiguate it from - there isn’t a concept of what a “ConcreteIO” would even be. > On Oct 21, 2015, at 3:50 PM, DNF <[email protected]> wrote: > > I understand. I'm just wondering why consistency between those two cases is > particularly important, when there are lots of other parts of the type > hierarchy where supertypes do not have the Abstract prefix. Is that the goal, > that all abstract types should have an 'Abstract' prefix to their names? > > On Wednesday, October 21, 2015 at 9:40:04 PM UTC+2, Jonathan Malmaud wrote: > It was motivated by consistency with strings. Initially there was Array <: > AbstractArray, but ASCIIString <: String. So to be consistent between those, > you have the choice of renaming things to get either > > 1) ConcreteArray <: Array and ASCIIString <: String or > 2) Array <: AbstractArray and ASCIIString <: AbstractString > > Since 1) would be a really difficult change to make because of all the > existing code, 2) was chosen. > > > >> On Oct 21, 2015, at 3:32 PM, DNF <[email protected] <javascript:>> wrote: >> >> I see that we are thinking the same way here :) I understand that there has >> been a push toward renaming abstract types AbstractXXX. Unless all abstract >> types are going to get the 'Abstract' prefix, I don't quite understand this. >> >> On Wednesday, October 21, 2015 at 9:19:30 PM UTC+2, Gabriel Gellner wrote: >> Continuing to think about all the ideas presented in this thread. It seems >> that the general advice is that almost all functions should at first pass be >> of "Abstract" or untyped (duck typed) versions. If this is the case why is >> Abstract not the default meaning for Array? Is this just a historical issue? >> This feels like the language design is sort of fighting this advice and >> instead it should have been that we have Array meaning AbstractArray and >> Array meaning something like ConcreteArray to put the incentive/most natural >> way to add types. Similar for Vector, Matrix etc. >
