[swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift
dgregor at apple.com
Mon Feb 1 14:10:25 CST 2016
> 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
>> 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).
> - "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:
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution