[swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)
howard.lovatt at gmail.com
Sat Jan 30 19:55:57 CST 2016
I disagree that a property should imply O(1), this is an implementation
detail that might change. For example an array based collection will almost
always have a count property that is O(1), but a liked-list based
collection will almost always be O(N).
On Friday, 29 January 2016, Michael Wells <michael at michaelwells.com> wrote:
> >> > ,----[ Side Note, since you mentioned efficiency ]
>> >> > | I originally wanted to uphold the principle that, “if it isn't
>> >> 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
>> >> > | elements of an Array was absurd.
>> >> > | 2. Programmers don't draw conclusions about efficiency based on
>> >> > | 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