[swift-evolution] [swift-evolution-announce] [Review] SE-0023 API Design Guidelines

Haravikk me at haravikk.com
Sat Jan 23 06:03:48 CST 2016

> On 23 Jan 2016, at 11:07, Thorsten Seitz via swift-evolution <swift-evolution at swift.org> wrote:
> I would actually prefer one of
> func loginWithUsername(username: String, password: String)
> func login(withUsername username: String, password: String)
> -Thorsten
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

I’m actually a big fan of the second definition, as it makes more sense to me for variations to be grouped by function name, as a login(withCertificate) or whatever is functionally identical, it just has different arguments to trigger it.

i.e- the function is named for what it will eventually perform (a login), and the parameters are named for what the function variant requires in order to perform that action, but in a form that allows the entire function declaration to be read like natural language.

I never really liked Objective-C’s grouping of the first parameter’s name into the function name, as you could end up with an object that has a loginWithUsername function and a separate loginWithCertificate function even though both do essentially the same thing. A lot of the methods of String for example suffer from this, which makes them quite a pain to use when dealing with “pure” Swift code (i.e- trying to work without any visible bridging to Objective-C).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160123/4cea28c2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1567 bytes
Desc: not available
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160123/4cea28c2/attachment.p7s>

More information about the swift-evolution mailing list