[swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)
michael at michaelwells.com
Thu Jan 28 10:52:23 CST 2016
> >> > ,----[ 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
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...
More information about the swift-evolution