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

[Howard Lovatt]

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

-- 
  -- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160131/6d0119b0/attachment.html>