Splitting *before* the last preposition tends to keep the
prepositional phrase together. Only leave the preposition on the base
name in rare cases where we would end up with weird argument labels
(e.g., prefer "moveTo(x:y:)" to "move(toX:y:)").
Also, refine our heuristics for when we can remove the preposition
entirely.
If the second argument label starts with a preposition for a split
selector, move the preposition into the first argument label. For
example:
- func transitionFrom(fromViewController: NSViewController, to
toViewController: NSViewController, options:
NSViewControllerTransitionOptions = [], completionHandler completion:
(() -> Void)? = nil)
+ func transition(from fromViewController: NSViewController, to
toViewController: NSViewController, options:
NSViewControllerTransitionOptions = [], completionHandler completion:
(() -> Void)? = nil)
Allow all keywords except for parameter introducers (var/let/inout) to
be argument labels when declaring or calling a
function/initializer/subscript, e.g., this
func touchesMatching(phase: NSTouchPhase, `in` view: NSView?) -> Set<NSTouch>
can now be expressed as
func touchesMatching(phase: NSTouchPhase, in view: NSView?) -> Set<NSTouch>
and the call goes from
event.touchesMatching(phase, `in`: view)
to
event.touchesMatching(phase, in: view)
Fixes [SR-344](https://bugs.swift.org/browse/SR-344) /
rdar://problem/22415674.
Ensures that the Swift lookup tables get transformed name for imported
CF types, including original name (which is still
available). Otherwise, this is an NFC refactoring that gets the last
of the naming tricks into importFullName.
The properties of a context indicate those things that are considered
"contained within" the context (among other things). This helps us
avoid producing overly-generic names when we identify a redundancy in
the base name. For example, NSView contains the following:
var gestureRecognizers: [NSGestureRecognizer]
func addGestureRecognizer(gestureRecognizer: NSGestureRecognizer)
func removeGestureRecognizer(gestureRecognizer: NSGestureRecognizer)
Normally, omit-needless-words would prune the two method names down to
"add" and "remove", respectively, because they restate type
information. However, this pruning is not ideal, because a view isn't
primarily a collection of gesture recognizers.
Use the presence of the property "gestureRecognizers" to indicate that
we should not strip "gestureRecognizer" or "gestureRecognizers" from
the base names of methods within that class (or its subclasses).
Note that there is more work to do here to properly deal with API
evolution: a newly-added property shouldn't have any effect on
existing APIs. We should use availability information here, and only
consider properties introduced no later than the entity under
consideration.
Cocoa's naming guidelines use lowercase initial words for selector
pieces and property names except when the first word is an
acronym. Force the first word of all imported APIs to be lowercase,
including acronyms.
Swift SVN r32719
"with"
Treat these prepositions as vacuous names, so we never reduce any
parameter name down to one of them. If that would happen, leave the
entire parameter name alone. This makes our transformation a bit more conservative.
Swift SVN r32460
Prepend "is" to Boolean property names (e.g., "empty" becomes
"isEmpty") unless the property name strongly indicates its Boolean
nature or we're likely to ruin the name. Therefore, the presence of
one of the following in the property name will suppress this
transformation:
* An auxiliary verb, such as "is", "has", "may", "should", or "will".
* A word ending in "s", indicating either a plural (for which
prepending "is" would be incorrect) or a verb in the continuous
tense (which indicates its Boolean nature, e.g., "translates" in
"translatesCoordinates").
Swift SVN r32458
When the first parameter of a function has Boolean type, try to create
an argument label for it. We start with the (normally non-API)
parameter name as the argument label, then try to match that against
the end of the base name of the method to eliminate redundancy. Add a
little magic, and here are some diffs:
- func openUntitledDocumentAndDisplay(_: Bool) throws -> NSDocument
+ func openUntitledDocument(display _: Bool) throws -> NSDocument
- func fontMenu(_: Bool) -> NSMenu?
- func fontPanel(_: Bool) -> NSFontPanel?
+ func fontMenu(create _: Bool) -> NSMenu?
+ func fontPanel(create _: Bool) -> NSFontPanel?
- func lockFocusFlipped(_: Bool)
+ func lockFocus(flipped _: Bool)
- func rectForSearchTextWhenCentered(_: Bool) -> NSRect
+ func rectForSearchText(whenCentered _: Bool) -> NSRect
- func dismissPreviewAnimated(_: Bool)
- func dismissMenuAnimated(_: Bool)
+ func dismissPreview(animated _: Bool)
+ func dismissMenu(animated _: Bool)
Swift SVN r32392
The special rule of introducing "body" isn't helping readability. We
might want to have a special rule around closure (or, especially,
trailing closure) parameters, but this is not it.
Swift SVN r32166
"Type" shows up in type names from time to time, but tends to be
omitted from selector pieces in such cases. This lets us skip that
suffix, fixing, e.g.,
- func changeCountTokenForSaveOperation(_: NSSaveOperationType) -> AnyObject
+ func changeCountTokenFor(_: NSSaveOperationType) -> AnyObject
Swift SVN r32165
Beyond the first parameter, the "with" or "using" at the beginning of
an argument label is needless, because one does not read the base name
of the method as if it distributed to the parameters. Some examples:
- func setProperty(_: String, withValue: AnyObject? = nil)
+ func setProperty(_: String, value: AnyObject? = nil)
- func hitTest(_: NSRect, withImageDestinationRect: NSRect, context:
NSGraphicsContext? = nil, hints: [String : AnyObject]? = nil,
flipped: Bool) -> Bool
+ func hitTest(_: NSRect, imageDestinationRect: NSRect, context:
NSGraphicsContext? = nil, hints: [String : AnyObject]? = nil,
flipped: Bool) -> Bool
- func track(_: NSRulerMarker, withMouseEvent: NSEvent) -> Bool
+ func track(_: NSRulerMarker, mouseEvent: NSEvent) -> Bool
Swift SVN r32141
Instead, when mapping a Clang type to its name for omission purposes,
map CF types to their appropriate names. This more directly mirrors
what will happen on the Swift side, but is otherwise NFC.
Swift SVN r32140
It's a cleaner rule to specify that we omit needless words from the
base name of a method and *then* split it for default arguments. This
tweak actually caught a small number of cases where we weren't
splitting properly, but should have.
Swift SVN r32133
When the context type of a declaraton matches the result type,
strip off redundant type information at the beginning of the
declaration name if it is followed by a preposition. This covers the
class of transformations on performs on a class that produce a value
of the same type as that class, e.g., NSURL's "URLWithHTTPS" or
NSString's "stringByAppendingString".
When that preposition is the magical "By" and is followed by a gerund,
strip the "By" as well. Note that this is slightly more conservative
now for methods, which previously stripped based on the result type
(always). For example, in NSCalendar:
- func adding(_: NSDateComponents, to: NSDate, options:
NSCalendarOptions = [])
-> NSDate?
+ func dateByAdding(_: NSDateComponents, to: NSDate, options:
NSCalendarOptions
= []) -> NSDate?
but it's more general for properties, e.g.,
- @NSCopying var bezierPathByFlattening: NSBezierPath { get }
- @NSCopying var bezierPathByReversing: NSBezierPath { get }
+ @NSCopying var byFlattening: NSBezierPath { get }
+ @NSCopying var reversing: NSBezierPath { get }
The important part is that the rules are more uniform and the code is
more regularly structured: we strip this leading type information when
it's redundant with the context and result type, regardless of whether
we have a property or a method, and the "By" rule is no longer special
in that regard.
Swift SVN r32129
This takes an highly-redundant API name like NSBezierPath's
func bezierPathByReversingPath() -> NSBezierPath
and turns it into
func reversing() -> NSBezierPath
Also, handle 'instancetype' properly when omitting words matching the
result type from the front of the base name.
Swift SVN r32119
Split the base name at the last preposition, but *only* when the first
parameter is defaulted, because defaulted arguments might not show up
at the call site and the longer base name can feel odd in such
cases. With this, stop avoiding the argument label "with": it's fine
when we have actual context at the call site, and the "with: nil" case
no longer happens now that we're defaulting nil.
Swift SVN r32098
