SE-0025: Scoped Access Level, next


(John Heerema) #1

I'm a fan of test-driven development.
I use it myself, and teach it to students and colleagues.

One of the nice things about Swift 1.0 was that it was easy to write module tests.

When access controls were introduced into Swift, I found that many functions and objects that had no genuine need to be public, suddenly had to become public in order to be tested. That just seems wrong to me.

I'd like to see a way for tests, which are not normally part of the module, to have access to a module's contents (I'm talking source only - not packages that do not include source). That might simply be a feature of the IDE, rather than a language feature.

On another note, I see "file private" (whatever it's called) as a legacy of C. I have trouble seeing it as being truly useful, but can see that others might have genuine uses for it (actually, I'd like to hear what they might be)

Thanks,
Dr. J. Heerema


(Rob Mayoff) #2

Check out the `testable` attribute:
https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Attributes.html#//apple_ref/doc/uid/TP40014097-CH35-ID347

Lots of examples if you type `swift testable` into your favorite search
engine.

···

On Fri, Apr 1, 2016 at 4:04 PM, John Heerema via swift-evolution < swift-evolution@swift.org> wrote:

I’m a fan of test-driven development.
I use it myself, and teach it to students and colleagues.

One of the nice things about Swift 1.0 was that it was easy to write
module tests.

When access controls were introduced into Swift, I found that many
functions and objects that had no genuine need to be public, suddenly had
to become public in order to be tested. That just seems wrong to me.

I’d like to see a way for tests, which are not normally part of the
module, to have access to a module’s contents (I’m talking source only –
not packages that do not include source). That might simply be a feature of
the IDE, rather than a language feature.

On another note, I see “file private” (whatever it’s called) as a legacy
of C. I have trouble seeing it as being truly useful, but can see that
others might have genuine uses for it (actually, I’d like to hear what they
might be)

Thanks,
Dr. J. Heerema

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Hart) #3

I’m fairly sure what you are asking for already exists with @testable: https://www.natashatherobot.com/swift-2-xcode-7-unit-testing-access/

···

On 01 Apr 2016, at 23:04, John Heerema via swift-evolution <swift-evolution@swift.org> wrote:

I’m a fan of test-driven development.
I use it myself, and teach it to students and colleagues.

One of the nice things about Swift 1.0 was that it was easy to write module tests.

When access controls were introduced into Swift, I found that many functions and objects that had no genuine need to be public, suddenly had to become public in order to be tested. That just seems wrong to me.

I’d like to see a way for tests, which are not normally part of the module, to have access to a module’s contents (I’m talking source only – not packages that do not include source). That might simply be a feature of the IDE, rather than a language feature.

On another note, I see “file private” (whatever it’s called) as a legacy of C. I have trouble seeing it as being truly useful, but can see that others might have genuine uses for it (actually, I’d like to hear what they might be)

Thanks,
Dr. J. Heerema

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution