[swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)

[Charles Kissinger]

> On Jan 27, 2016, at 11:13 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> on Wed Jan 27 2016, Charles Kissinger <swift-evolution at swift.org> wrote:
> 
>>> On Jan 27, 2016, at 11:23 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>>> 1. I don't know how to nail down what was meant by “intrinsic” in:
>>> 
>>>    Things that are “intrinsic” to the receiver are properties
>> 
>> How about: If something is, or logically could be, a value stored in
>> memory as part of the object, it is intrinsic.
> 
> That's apparently not what was meant, because the group decided that
> collection.min() should be a method... unless you have some reason to
> assert that the minimum could /not/ be stored in a collection.

Properties of collection types seem like a special case because so many potential candidates are likely to have O(n) behavior. Was a “most common case” rule being implicitly applied by the group here, where ‘count' is a property because it is O(1) for the most prominent collection types, while min() is a method because it is commonly O(n)?

— CK

>> 
>>> 3. I don't understand the rationale we currently have for
>>>  sequence.iterator() not being a property, even though I think that's
>>>  the right choice.
>> 
>> To me, a sequence.iterator property would suggest there is one such
>> thing that is intrinsic to the sequence. A sequence.iterator() method
>> better expresses the idea that there can be multiple independent
>> iterators existing at once (for multi-pass sequences anyway).
> 
> Yes, that's much closer to the rationale I had been using for myself.
> 
>> —CK
>> 
>>> -- 
>>> -Dave
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> -- 
> -Dave
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution