[swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)
crk at akkyra.com
Fri Jan 29 10:20:23 CST 2016
> 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)?
>>> 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.
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>> swift-evolution mailing list
>> swift-evolution at swift.org
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution