First, let me say that basic premise was intended to be “I would like the
ability to have a protocol for dictionary-type objects rather than have it be a
single implementation for several reasons, but I expect that there would also
be several hurdles to doing so”. It is more of an idea than a design or
proposal at this point, partly because I suspect some of the hurdles may either
be blocking until other enhancements land in Swift, or that having a concrete
dictionary type is just preferred based on the design goals of the language.
My interface was just a copying of the methods on Dictionary which I thought
made sense for illustration purposes.
<rest inlnine>
> On Dec 31, 2015, at 2:27 PM, Dave Abrahams <dabrah...@apple.com> wrote:
>
>>
>> On Dec 31, 2015, at 11:17 AM, David Waite <da...@alkaline-solutions.com
>> <mailto:da...@alkaline-solutions.com>> wrote:
>> An AssociativeCollectionType would allow for alternate implementations from
>> Dictionary, which provide space optimization, lookup performance, and
>> functionality, to be used closer to the level of first-class citizenship
>> that Dictionary has.
> That’s pretty abstract. Note also that one shouldn’t design protocols
> without a batch of concrete models that you can examine to see how they
> should conform.
Languages like Java and C# which are interface heavy come with a wide
assortment of collections implementations, and third party implementations of
even more. I’ve implemented core collection types (in Mono) and several of my
own custom implementations over the years in these languages.
And yes, I would expect design and implementation to go hand-in-hand for just
about any collections changes - although the current process for swift
evolution does not integrate as well as I personally would like with iterative
or prototype-driven design, that would be my personal preferred approach for
any larger feature, especially one impacting the collections portion of the
standard library.
>> Some of this though is that many CollectionType and SequenceType operations
>> are useful when considering a Dictionary as a sequence in a functional style
>> - but is not the default way I at least think of Dictionaries. For instance,
>> how often will people want to filter a dictionary into a tuple array, vs
>> mutating or forming a new dictionary with predicate-failing entries removed?
>>
>> As least in my personal experience, the difference in relationship between
>> Array and CollectionType (Array being a type of collection) and Dictionary
>> and CollectionType (dictionaries can be represented by a collection) is a
>> constant source of confusion.
>
> That sounds like a different issue. Are you suggesting dictionaries should
> have-a collection rather than be-a collection?
Oh boy. Prefacing with “I am unsure if I want to get into that conversation due
to the impact being too great for any bike shedding to ever be relevant”,
mostly yes. If it is worth further discussion, it is probably worth doing so in
a separate thread.
A Dictionary is as representable as a collection as a Set would be. The
underlying implementation of both both could just as well be an array of
optionals (I’ve implemented one as such).
However, there is a pattern in Swift collections of pushing down as much
default implementation as possible balanced against the expense of a naive
default implementation. As such, there is a complexity imported directly into
Dictionary to deal with what I perceive as a secondary representation of the
information in the dictionary - a list of key, value pairs.
>
>> Some the cons I’ve identified:
>> - Protocols today do not have generic arguments, making any function
>> declaration wanting to take “any string to string associative collection” vs
>> “[String:String]” be significantly more complex.
>
> I don’t see why you think that increases complexity. I don’t agree that it
> does. This also seems like a completely separate issue from whether we have
> AssociativeCollection.
I was speaking to the declarative complexity and verbosity in today’s syntax:
func process(data:[String:String])
vs.
func process<ACT:AssociativeCollectionType where ACT.Key == String,
ACT.Value == String>(data:ACT)
This would make it very difficult for one to have a custom implementation of an
associative collection which accepted by third party code, simply because the
API designers went with the simpler, more readable syntax.
>>
>> - It is more pragmatic and simpler from a type perspective to push code to
>> use a single Array or Dictionary implementation rather than needing to
>> support generic implementations, except when opted into. This is similar to
>> the use of lazy, or the use of Int vs smaller or more specific types.
>
> True, and it will always be that way AFAICT. And again this seems like a
> completely separate issue.
I don’t know if it is an issue - it may very well be an explicit design goal to
reduce decisions around types. I say that it *may* be an explicit design goal,
because some of the cases cited may indeed be the result of the featureset of
the current language.
I can’t say if the push toward using Int for everything would be lessened with
an updated numerics system, or if operations like map return arrays rather than
a new sequence because of current limitations in the generics system - I simply
don’t know.
-DW_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
