Skip to content

Add 'open' to all public classes and their members. #150

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

Merged
merged 1 commit into from
Aug 1, 2016

Conversation

jrose-apple
Copy link
Contributor

This can probably be refined by the XCTest team in a later commit.

In preparation for landing SE-0117.

This can probably be refined by the XCTest team in a later commit.

In preparation for landing SE-0117.
@jrose-apple
Copy link
Contributor Author

cc @mike-ferris-apple, @rjmccall

@swift-ci Please test

@@ -39,17 +39,17 @@ public class XCTest {
/// ensure compatibility of tests between swift-corelibs-xctest and Apple
/// XCTest, you should not set this property. See
/// https://bugs.swift.org/browse/SR-1129 for details.
public public(set) var testRun: XCTestRun? = nil
open open(set) var testRun: XCTestRun? = nil
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@rjmccall, is this correct?

@modocache
Copy link
Contributor

Looks good to me, thanks @jrose-apple!

A later commit should probably revise some of these.

  • XCTestSuite, XCTestCaseRun and XCTestSuiteRun, for example, are probably not meant to be open, and instead should be marked public.
  • XCTestRun is also probably only meant to be subclassed by XCTest{Suite,Case}Run, and so should be public (not open) as well.

Thoughts, @mike-ferris-apple, @briancroom?

@mike-ferris
Copy link

I’d say that first goal should be equivalence with Xcode's XCTest…

That said, it might be interesting to assess the API and make changes to the swift side of both Xcode’s and CoreLib's XCTest in concert.

Mike
'

On Aug 1, 2016, at 12:45 PM, Brian Gesiak [email protected] wrote:

Looks good to me, thanks @jrose-apple https://github.com/jrose-apple!

A later commit should probably revise some of these.

XCTestSuite, XCTestCaseRun and XCTestSuiteRun, for example, are probably not meant to be open, and instead should be marked public.
XCTestRun is also probably only meant to be subclassed by XCTest{Suite,Case}Run, and so should be public (not open) as well.
Thoughts, @mike-ferris-apple https://github.com/mike-ferris-apple, @briancroom https://github.com/briancroom?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #150 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/APF4U8KHReboBl4HanjN9FfUdT3OR18uks5qbky8gaJpZM4JZ21W.

@modocache
Copy link
Contributor

@mike-ferris-apple I believe swiftlang/swift#3882 will import all Objective-C classes from Xcode XCTest as open. The changes in this pull request makes corelibs-xctest equivalent.

By my comment above, I meant I think both the Swift overlay for Xcode XCTest and swift-corelibs-xctest should declare XCTestSuite, XCTestRun, XCTestCaseRun, and XCTestSuiteRun as public. I believe these classes are not meant to be subclassed by users of XCTest -- does that sound right?

@mike-ferris
Copy link

On Aug 1, 2016, at 2:25 PM, Brian Gesiak [email protected] wrote:

@mike-ferris-apple https://github.com/mike-ferris-apple I believe swiftlang/swift#3882 swiftlang/swift#3882 will import all Objective-C classes from Xcode XCTest as open. The changes in this pull request makes corelibs-xctest equivalent.

That's what I figured.
By my comment above, I meant I think both the Swift overlay for Xcode XCTest and swift-corelibs-xctest should declare XCTestSuite, XCTestRun, XCTestCaseRun, and XCTestSuiteRun as public. I believe these classes are not meant to be subclassed by users of XCTest -- does that sound right?

Well, practically speaking I think that’s true, and it might be good to try to lock things down a bit. I believe that XCTestRun would need to be subclassed by folks adding new subclasses of XCTest, but I am not sure how practical a use case that is.

I am not up to speed on exactly what we’re solving by introducing this distinction, also, and I would be somewhat cautious about cutting off subclassability just because we can’t think of a reason you’d want to…

For example, does closing off XCTestSuite and XCTestSuiteRun gain us anything? It certainly loses us the case of someone discovering something cool they could do by doing this only to find that they can’t. I need a philosophy lesson (and perhaps technology lesson) as to the appropriate use for this distinction in Swift.

I’d say that at the very least this requires some fairly deep thinking. And probably that thinking should consider how prepared the rest of the overall context in which XCTest exists (on the Xcode side) is affected. in fact, what the IDE and larger testing infrastructure is designed/prepared for is potentially one of the more compelling reasons to close stuff off...

Mike

@modocache
Copy link
Contributor

Awesome, thanks for the detailed response. I'm looking forward to hearing what the XCTest team decides on which APIs should be open or public. It'd be great if you all shared that discussion on the mailing lists! 🙏

Anyway, sorry for the noise on this pull request... 😅

@rjmccall
Copy link
Contributor

rjmccall commented Aug 1, 2016

Okay, we're just going to merge this in; thanks, all.

@rjmccall rjmccall merged commit e30df50 into swiftlang:master Aug 1, 2016
@jrose-apple jrose-apple deleted the open-for-business branch August 1, 2016 22:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants