Hi Everyone,
I posted something along these lines a couple of weeks back, but I wanted to raise it more formally:
Given that the standard for Swift classes is to not include prefixes, I’d love to see (and contribute to) the “XC” being dropped from XCTest.
I’d propose that it’s important/core enough to warrant changing from “XCTestCase” to “Swift.TestCase" (et al) or something very similar.
What are people’s thoughts on this?
Tony
I’d propose that it’s important/core enough to warrant changing from “XCTestCase” to “Swift.TestCase" (et al) or something very similar.
`Swift.` would mean XCTest had been merged into the standard library, which I don't think is something we should do.
We could drop the `XC` prefixes from the APIs, giving us e.g. `XCTest.TestCase`; that might be a good idea. We could also drop the `XC` prefix from the module itself, giving us `Test.TestCase`, but I think that might be a bridge too far—we're going to start getting other testing frameworks soon enough.
--
Brent Royal-Gordon
Architechies
Sorry I haven't been following the evolution process very closely: will prefixes be dropped from the SDK overlays? In other words: will Apple XCTest's "XCTestCase", when used from Swift, be named "TestCase"?
I ask because the primary goal of swift-corelibs-xctest is to allow developers to write one set of tests that will seamlessly work on all platforms. So I think corelibs-xctest will continue to use whatever names Apple XCTest uses--after all, it would be a pain if developers had to write:
#if os(Darwin)class MyTestCase: XCTestCase {#elseclass MyTestCase: TestCase { // ...}
- Brian Gesiak
_____________________________
From: Tony Arnold via swift-corelibs-dev <swift-corelibs-dev@swift.org>
Sent: Friday, February 26, 2016 7:48 PM
Subject: [swift-corelibs-dev] Changing the name of XCTest* to Test*
To: <swift-corelibs-dev@swift.org>
Hi Everyone,
I posted something along these lines a couple of weeks back, but I wanted to raise it more formally:
Given that the standard for Swift classes is to not include prefixes, I’d love to see (and contribute to) the “XC” being dropped from XCTest.
I’d propose that it’s important/core enough to warrant changing from “XCTestCase” to “Swift.TestCase" (et al) or something very similar.
What are people’s thoughts on this?
Tony
----------
Tony Arnold
+61 411 268 532
http://thecocoabots.com/
ABN: 14831833541
_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
The answer is “no”. We are still planning to drop the “NS” prefix (specifically, not other prefixes) off of some imported values, but the exact details are TBD. Of course corelibs-foundation and the darwin-foundation will be kept in sync. If a type drops “NS”, we’ll drop it in both places.
-Chris
On Feb 27, 2016, at 6:40 AM, Brian Gesiak via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
Sorry I haven't been following the evolution process very closely: will prefixes be dropped from the SDK overlays? In other words: will Apple XCTest's "XCTestCase", when used from Swift, be named "TestCase”?
The answer is “no”. We are still planning to drop the “NS” prefix (specifically, not other prefixes) off of some imported values, but the exact details are TBD. Of course corelibs-foundation and the darwin-foundation will be kept in sync. If a type drops “NS”, we’ll drop it in both places.
Understood.
`Swift.` would mean XCTest had been merged into the standard library, which I don’t think is something we should do.
Please ignore my ignorance there. I’m (still) not across out how all the pieces fit together.
We could drop the `XC` prefixes from the APIs, giving us e.g. `XCTest.TestCase`; that might be a good idea. We could also drop the `XC` prefix from the module itself, giving us `Test.TestCase`, but I think that might be a bridge too far—we’re going to start getting other testing frameworks soon enough.
I think this makes sense — the library is XCTest, the class is TestCase. Having XYZ.TestCase from another vendor is perfectly reasonable in my opinion.
I guess there’s a bunch of things that shake out of that though, like do you then rename XCTAssert(…) to Assert(…), etc.
It feels (oh god, the feels) like there’s an opportunity to simplify the names of some things here, but I understand there’s plenty of bigger fish to fry.
Thanks all :)
-t
On 28 Feb 2016, at 16:45, Chris Lattner <clattner@apple.com> wrote:
On 28 Feb 2016, at 07:03, Brent Royal-Gordon <brent@architechies.com> wrote:
----------
Tony Arnold
+61 411 268 532
http://thecocoabots.com/
ABN: 14831833541
I don't have any insight into the core team's thinking on this, but dropping "XC" wouldn't make sense to me, given that XCUnit is just one of many "xUnit"-style unit testing frameworks. The "XC" prefix here is part of a disambiguating namespace for the different xUnit testing frameworks:
xUnit - Wikipedia
List of unit testing frameworks - Wikipedia
Even way down the track, dropping the prefix makes no sense to me. (Moving to a completely new testing framework with a completely different name - that's not impossible, but also an entirely different kettle of fish, and not one that I think anyone need concern themselves with.)
Cheers,
M.
On 28 Feb 2016, at 13:45, Chris Lattner via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
On Feb 27, 2016, at 6:40 AM, Brian Gesiak via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
Sorry I haven't been following the evolution process very closely: will prefixes be dropped from the SDK overlays? In other words: will Apple XCTest's "XCTestCase", when used from Swift, be named "TestCase”?
The answer is “no”. We are still planning to drop the “NS” prefix (specifically, not other prefixes) off of some imported values, but the exact details are TBD. Of course corelibs-foundation and the darwin-foundation will be kept in sync. If a type drops “NS”, we’ll drop it in both places.
-Chris
--
Mark Glossop
E: lists@cueballcentral.com
TW: http://twitter.com/Cueball_AU