-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Review diffs between Swift 2 --> preliminary Swift 3 API #4078
Conversation
- public func indexOf(predicate: NSPredicate) -> Int? | ||
- public func indexOf(predicateFormat: String, _ args: AnyObject...) -> Int? | ||
+ public func index(of object: T) -> Int? | ||
+ public func indexOfObject(for predicate: NSPredicate) -> Int? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for
feels odd here. It reads as "index of object for predicate". Something like "index of object matching predicate" would be clearer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd propose index(of object: T)
and index(matching predicate: NSPredicate)
.
I have some recommendations: az/swift3apireview...jp/swift3apireview I can make those edits directly on this branch if that's ok with @austinzheng. |
@jpsim That's absolutely fine with me. Same with anyone else who wants to push suggestions as additional commits. |
@austinzheng merged, thanks. |
I want to start applying these changes later today, so I encourage anyone who still has feedback to give on these APIs to do that soon. |
Everything looks reasonable to me now. |
Looks good to me as well. Should |
I'd say no, due to those being the wrong words. "Automatically Refresh" already accurately represents the behavior, but not worth expanding from the current shortened form of |
I've applied the changes from the diff to our APIs. |
525d65f
to
c4ee14b
Compare
2 CI failures are due to The first one we could add to the "known Xcode error" detection in build.sh to rerun the job, the second one seems like something that could fixed by adapting |
I'd like to merge this tomorrow, so I'd appreciate a quick review. You'll find the completes docs diff with 1.0.2 & Swift 2 here: https://gist.github.com/jpsim/87002160be20193eb4b85a2ea1905231 Realm Swift 1.0.2 Swift 2.2 docs here: https://realm.io/docs/swift/latest/api Looks like |
I think Jazzy doesn't (yet) know how to deal with declarations marked with |
I think you're right. It has partial support for it, but not complete. |
👍 , based on the diff changes you made. Should we remove the |
@@ -300,7 +300,7 @@ public final class Realm { | |||
:nodoc: | |||
*/ | |||
@discardableResult | |||
public func createDynamicObject(ofType typeName: String, populatedWith value: Any = [:], update: Bool = false) -> DynamicObject { | |||
public func dynamicCreate(_ typeName: String, value: Any = [:], update: Bool = false) -> DynamicObject { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be nice for this to share a prefix with create
. For example, create(typeNamed:value:update:)
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function's name starts with dynamic
to prevent it from showing up in autocorrect since it's not what users want 99% of the time. Ideally we'd have Clang submodules in Swift and expose it in there, but alas we don't, so we namespace it like this.
Yes of course. I was waiting for this to pass review before doing that so that we can double check that my changes are correct based on our discussions around the
This was an easy fix in jazzy (realm/jazzy#655). I've updated the gist and API docs I linked to above. |
@bdash is the change you made in 0d7e7a1 to make See http://static.realm.io/jazzy_demo/RealmSwift3/Structs/Error.html Unless I'm missing something, I suggest we switch that back to an enum. |
If we want to not make adding new error enum cases a breaking change, it needs to be a struct. Otherwise, it can be an enum. |
Good point. It'd still be nice to improve how the documentation for this is generated. Maybe moving the doc strings onto the Error members directly rather than the Code would be doable? |
3da08b7
to
6a37c83
Compare
Can't set status; build failed. |
Changes: - Documentation for Swift 3 APIs is now correct - Fixed an inconsistency where some APIs were `sorted(property:...)` rather than `sorted(byProperty:...)` - All Swift 3 enum case members are lowerCamelCase now
Fixing documentation for Swift 3 APIs
@austinzheng @tgoyne @bdash I think this is ready to land. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
@jpsim @bdash @tgoyne @stel @mrackwitz @kishikawakatsumi @TimOliver @JadenGeller