[swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift

[Douglas Gregor]

> On Jan 29, 2016, at 12:07 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Jan 28, 2016, at 14:15, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> I'm very used to "fooWithBar: baz" meaning either "get me the foo that
>>> has a bar matching baz" or "create me a foo with its bar set to
>>> baz". 
>> 
>> That's great, when that's what "with" means.
>> 
>>> But I'm not sure this new convention is any worse, now that the base
>>> name isn't assumed to include the first argument.
>> 
>> The problem is that, I'm guessing at least 50% of the time, "with" is
>> just used as a vacuous connector to make the method name sound
>> grammatical, and "fooWithBar" doesn't actually mean the "foo" has-a
>> "bar."  In these cases, it's actively misleading. I know that's not what
>> you were posting about, but I felt it had to be said :-/
> 
> I actually don't think this is true when "foo" is a noun (and searching through the selector dump Doug made a long time ago seems to back that up).
> 
> Exceptions:
> - "fooWithOptions", but that's already caught by the default parameter rule.
> - "fooWithLocale", which uses the locale to build the result.
> - "commonPrefixWithString", where the "with" isn't quite vacuous.
> 
> But when "foo" is a verb (or when it's a later parameter that's just "withBar") it does seem pretty vacuous.

This is a great observation. Pull request here shows what this does:

	https://github.com/apple/swift-3-api-guidelines-review/pull/9

and, from the cases we’ve looked at, does a fantastic job of distinguishing the cases where “with” is a separator vs. “with” meaning some kind of selection criteria.

	- Doug


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160201/e71a7c14/attachment.html>