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

[Dave Abrahams]

on Sat Jan 30 2016, Howard Lovatt <swift-evolution at swift.org> wrote:

> I disagree that a property should imply O(1), this is an implementation
> detail that might change. 

Not that I really want to argue this, as I am resigned to the fact that
we will not tie performance to property-ness, but...

Efficiency characteristics are no mere implementation detail, at least
not in the standard library.  

> For example an array based collection will almost always have a count
> property that is O(1), 

You can strike "almost" :-)

> but a liked-list based collection will almost always be O(N).

It really depends on whether you allow O(1) splicing.  Without
supporting O(1) splicing, it's really easy for a linked list
to have an O(1) count.  And with cacheing, you can even arguably have an
amortized O(1) count.

But even if a linked list has O(N) count, I don't see that what you're
describing indicates anything, by itself, about whether something being
a property should have performance implications.  There has to be an
underlying assumption that an Array's count must be a property, or
something else of that sort, in the background.

> 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
>>> 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. :-)
>>
>>
>>
>>
>>
>>

-- 
-Dave