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

[Michael Wells]

> >> > ,----[ Side Note, since you mentioned efficiency ]
> >> > | I originally wanted to uphold the principle that, “if it isn't O(1),
> >> you
> >> > | don't make it a property.”  The implication is that on collections,
> >> > | “count” would be a method.  That would include Array, for which
> >> counting
> >> > | the elements *is* O(1).  Some people argued that:
> >> > |
> >> > | 1. The idea of writing “a.count()” instead of “a.count” to count the
> >> > |    elements of an Array was absurd.
> >> > | 2. Programmers don't draw conclusions about efficiency based on whether
> >> > |    something is a property.
> >> > | 3. The fact that Array would have an O(1) non-property that *could*
> >> have
> >> > |    been a property (if it weren't for CollectionType conformance)
> >> > |    undermines any communicative power that you might get from using
> >> this
> >> > |    distinction to choose properties.
> >> > |
> >> > | I did not win that argument :-)

I strongly agree that properties imply O(1) and most programmers I’ve ever worked with make the same assumptions. Even if the documentation says otherwise, code like

fibonacciNumbers.count

looks as if you’re accessing a c-style field ‘count’ and that implies (at least to me) that it is a near-costless operation. Some of the biggest design mistakes I’ve ever seen use properties that trigger time-consuming operations like database or network access. 

And I don’t think having to use a.count() is absurd. :-)





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160128/916d2fbb/attachment.html>