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

[Rod Brown]

I can't believe I let it get this far before I began to post regarding these language proposals.

> What is your evaluation of the proposal?
I like the proposal, and the direction it shows for Swift. I'm particularly fond of the concise nature of the language.

I wonder specifically whether cases of ivars should be lower or upper case. I tend to think lower case makes more sense in the context of Swift, but I am personally fond of the upper camel case. Perhaps my eyes have just grown accustomed?

I am particularly in favour of the sort() vs sorted() verb vs noun. I definitely see the points raised and acknowledge that the subtleties of language mean there will always be exceptions to rules where it doesn't make sense, and I think the "inPlace" wording makes sense to fill this gap.

I'm personally not a fan of the strong guidance to eliminate initial argument labels. I find this somewhat of a holdover from the awkward translation of Obj-C APIs, and I think there are cases where the initial parameter makes sense to be named. The login example, while it has its flaws, makes some sense here.

loginWithUsername("Rod", password: "Password")
vs
login(username:"Rod", password: "Password")

Placing the WithUsername prior to the bracket implies that the username has more importance, at least to my eye. As has been discussed, it probably does have more importance, but I think it makes a fair point that there are cases where both arguments are simply peers that should be labeled without emphasis on the leading item. I think that naming each parameter for clarity makes sense in those cases, and this should be noted in documentation. 

For all other elements, I am definitely in favour.


> Is the problem being addressed significant enough to warrant a change to Swift?
I definitely think the language benefits from guidance like this. I wonder whether we may need to come back and review this in a few years as we see where Swift goes, but my hope is it keeps the same basic feel.


> Does this proposal fit well with the feel and direction of Swift? 
These language directions seem very consistent with Swift's direction.


> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I find languages with clear guidelines tend to be somewhat more ordered. I'm definitely in favour of the a reference document that outlines standard practice, as it is beneficial both when teaching, and when reading people's code. Consistency breeds clarity, and these







> On 31 Jan 2016, at 3:09 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
>> 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
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160201/f31becc7/attachment.html>