Skip to content
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

Merged
merged 37 commits into from
Sep 15, 2016

Conversation

austinzheng
Copy link
Contributor

@austinzheng austinzheng self-assigned this Sep 12, 2016
- 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?
Copy link
Contributor

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.

Copy link
Contributor

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).

@jpsim
Copy link
Contributor

jpsim commented Sep 13, 2016

I have some recommendations: az/swift3apireview...jp/swift3apireview

I can make those edits directly on this branch if that's ok with @austinzheng.

@austinzheng
Copy link
Contributor Author

austinzheng commented Sep 13, 2016

@jpsim That's absolutely fine with me. Same with anyone else who wants to push suggestions as additional commits.

@jpsim
Copy link
Contributor

jpsim commented Sep 13, 2016

@austinzheng merged, thanks.

@jpsim
Copy link
Contributor

jpsim commented Sep 13, 2016

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.

@tgoyne
Copy link
Member

tgoyne commented Sep 13, 2016

Everything looks reasonable to me now.

@austinzheng
Copy link
Contributor Author

Looks good to me as well.

Should autorefresh (a boolean property) be something like willAutorefresh or isAutorefreshing?

@jpsim
Copy link
Contributor

jpsim commented Sep 13, 2016

Should autorefresh (a boolean property) be something like willAutorefresh or isAutorefreshing?

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 autorefresh. Given that we can't change the Objective-C property name, I'd prefer aligning the Swift one too.

@jpsim
Copy link
Contributor

jpsim commented Sep 13, 2016

I've applied the changes from the diff to our APIs.

@jpsim jpsim force-pushed the az/swift3apireview branch from 525d65f to c4ee14b Compare September 13, 2016 20:40
@jpsim
Copy link
Contributor

jpsim commented Sep 13, 2016

2 CI failures are due to Abort trap 6 when running xcodebuild and Application "io.realm.TestHost" is unknown to FrontBoard. in CoreSimulator.log.

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 reset-simulators.sh to launch the same simulator device as the job will use I think...

@jpsim
Copy link
Contributor

jpsim commented Sep 14, 2016

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
Realm Swift master Swift 3.0 docs here: https://static.realm.io/jazzy_demo/RealmSwift3

Looks like Object isn't documented at all for Swift 3, which I'll look into now.

@austinzheng
Copy link
Contributor Author

I think Jazzy doesn't (yet) know how to deal with declarations marked with open.

@jpsim
Copy link
Contributor

jpsim commented Sep 14, 2016

I think Jazzy doesn't (yet) know how to deal with declarations marked with open.

I think you're right. It has partial support for it, but not complete.

@austinzheng
Copy link
Contributor Author

👍 , based on the diff changes you made.

Should we remove the .diff file from the final PR?

@@ -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 {
Copy link
Contributor

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:).

Copy link
Contributor

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.

@jpsim
Copy link
Contributor

jpsim commented Sep 14, 2016

Should we remove the .diff file from the final PR?

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 .diff.

I think Jazzy doesn't (yet) know how to deal with declarations marked with open.

I think you're right. It has partial support for it, but not complete.

This was an easy fix in jazzy (realm/jazzy#655). I've updated the gist and API docs I linked to above.

@jpsim
Copy link
Contributor

jpsim commented Sep 14, 2016

@bdash is the change you made in 0d7e7a1 to make RealmSwift.Error a struct still necessary? It still seems better suited as an enum to me, and the fact that it's a struct with its members only documented indirectly via its Code equivalent member complicates the docs.

See http://static.realm.io/jazzy_demo/RealmSwift3/Structs/Error.html

image


Unless I'm missing something, I suggest we switch that back to an enum.

@austinzheng
Copy link
Contributor Author

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.

@jpsim
Copy link
Contributor

jpsim commented Sep 14, 2016

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?

@jpsim jpsim force-pushed the az/swift3apireview branch from 3da08b7 to 6a37c83 Compare September 14, 2016 05:48
@realm-ci
Copy link
Contributor

Can't set status; build failed.

Austin Zheng and others added 5 commits September 14, 2016 12:48
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
@jpsim
Copy link
Contributor

jpsim commented Sep 15, 2016

@austinzheng @tgoyne @bdash I think this is ready to land.

Copy link
Member

@tgoyne tgoyne left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@jpsim jpsim merged commit 41db543 into master Sep 15, 2016
@jpsim jpsim deleted the az/swift3apireview branch September 15, 2016 21:29
@jpsim jpsim removed the S:Review label Sep 15, 2016
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 15, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants