Access Control on Andrew Bancroft

Swift Framework Woes – Unresolved Identifier? No Member?

Fri, 08 Jan 2016 18:40:55 +0000

It’s the simple things that get us, isn’t it?

I was working on a simple little framework the other day, and I’d gotten things just how I wanted… or so I thought.

I was ready to test things out and import the framework into my real app.

import MyShinyNewFramework

Sweet! No build errors!

// attempt to use things defined in the framework

Not so sweet…

Use of unresolved identifier ‘…'

Value of type ‘…’ has no member ‘…'

I scrunched my forehead, puzzled, and immediately it came to me.

public public public all the things! Or at least, the things that others need to use from the framework. :]

Of course a framework’s usable API needs to be public, but I write far more code that doesn’t require thought of access control modifiers than code that does, so there’s always that initial head-scratching that happens when you’re to the point of testing and go, “WHAT?? Why is this not working??!”

Key Takeaway

Whenever you’re developing code (such as a framework) that’s intended to be used from the perspective of another Swift module, you need to include public before Types and functions that are intended to be “seen” and called from that other module. Otherwise, you’ll get those same fun compiler errors and join me in saying to yourself, “Doh! Yep… public… again.”

Clarifying Swift Access Control (Hint: Swift Isn’t C#)

Fri, 24 Apr 2015 18:02:34 +0000

As it turns out, Swift isn’t C# (or Java or VB.Net or…)! My day job keeps me busy writing C#, so I’ll reference it as my go-to comparison language for this article. The conclusion, however, carries over to other languages that have access control modifiers.

I just spent the greater part of a week experimenting with Swift extensions. I was trying to figure out some seemingly strange behavior that they were exhibiting.

After publishing “3 Nuances of Swift Extensions”, I quickly learned that I had a fundamental misunderstanding of Swift access control, thanks to some observant folks in the Swift community.

What was the hiccup? Read on to find out where I went wrong…

How private is private?

One of the most surprising “nuances” from “3 Nuances of Swift Extensions” that I discovered was that if you define an extension within the same source file as another Type, the extension’s members can see the other Type’s private properties and functions! “Whaaat?? How is this possible?!”, I reacted.

Well… To restate the obvious, Swift isn’t C#… and it isn’t C# in more ways than just syntax.

Ever since access control modifiers were introduced in Xcode 6 Beta 4, I had it in my mind that public, private, and internal worked just like they do in C#. Sure, I read the blog article on access control published by the Swift team, but it was a mere cursory look. I basically saw the three key words and thought, “Ah, I got this… moving on!”

This was a fundamental mistake for me to make, and it goes to show that just because there are similarities between languages, it doesn’t mean the semantics of those similarities carry over.

Semantics of private

Private is the access modifier that got me all confused. The concept of public and internal carry over fairly nicely, but private is the one that’s fundamentally different between C# and Swift, so that’s where I’ll focus.

In addition to this article, recommend giving the Swift team’s original article on access control a very close read, just to make sure all the semantics of public and internal in Swift are clear as well.

Private and C#

In C#, private members of a Type are “truly” private. They are only visible within that Type. The member’s visibility is limited to the curly braces enclosing the Type’s implementation. That’s it. No subclass can see private members. No other Types can see those members, no matter which file those Types are defined in. Private is private.

Private and Swift

And then there’s Swift. Private takes on entirely different semantics in Swift, and herein lay my fundamental misunderstanding. It was obvious that I just didn’t “get it” if you read through the Nuances Article. [sigh]

In Swift, a private Type, or a public/internal Type’s private members are visible to anything else defined within the same file.

This isn’t a characteristic that’s limited to extensions. Anything defined in the same source file as something else can see everything. This is a shocker if you’re coming from C# or a similar language where the semantics of access control are used for encapsulation purposes.

Proof by example

So suppose you have a file named Types.swift, and within you have the following:

1private struct Person {
2    private let name: String
3}
4
5private struct Greeter {
6    private func greet(person: Person) {
7        println("Hi, I'm \(person.name)")
8    }
9}

If you’re a C# developer, you look at that code and immediately go, “Yeah, that’s not gonna work… name is private to Person and can’t be referenced outside that Type”.

But in Swift, this is totally legitimate. Even though Person is private, Greeter can see Person and initialize one, and it can see Person‘s private property, name.

Private in Swift simply limits visibility to Types and members within the same source file. Multiple Types defined in the same source file can see other private Types, as well as other Types’ private properties and functions. In other words, “private isn’t private”, if you’re thinking of private like a C# developer (or a developer familiar with other languages with access control modifiers similar to C#).

Wrapping up

There is a fundamental difference in the semantics of access control between C# and Swift.

In C#, we typically think of access control in terms of inheritance characteristics. The modifiers affect the Type and revolve around the Type and its interaction with other Types.

Swift, controls access to members in terms of source file and module. Types defined within the same source file see everything about each other, including private members. Internal Types and members expand visibility to anywhere within the same module. Finally, public access makes Types and their members visible everywhere, even to Types defined in other modules.

Testability Tip for Swift Developers – Public Over Private

Wed, 15 Apr 2015 18:52:11 +0000

Quite often in unit testing, especially when practicing Test-Driven Development, I find myself wanting to test every single line of code. When I run up against a private function, however, I often scratch my head and ask, “How am I supposed to test this??”.

Most experienced testers will tell you, “Don’t test private implementation – only public API”.

“Okay… But how, does that private function get tested?”, I always asked.

In this article, I intend to share a testability tip catered to the Swift developer community that helps alleviate this issue with testing private functions.

Testing and observability

Developers as clients of APIs

As developers, we are “clients” of APIs on a daily basis. We interact with other developers’ frameworks and libraries through the visible, observable, Application Programming Interface that they’ve exposed to us. It’s the way they’ve designed for us to interact with their code.

Notice three words that I chose in that introductory paragraph:

Visible
Observable
Exposed

If we are going to use another developer’s library, all we have as developers is the public interface that they’ve made visible to us… It’s the only observable thing we can look at and go, “Oh! Okay, to do this, I call that function”. The only thing exposed are the functions and properties that the developer intends for us to see.

Tests as clients of APIs

Have you ever viewed your unit test suite as a “client” of your code? It is!

And just like a developer, the unit tests in your test target interacts with your app’s API through the same visible, observable, interface that you’ve exposed to them.

If you start to personify your test target and think of it in terms of “just another client of your code”, you begin to see that it really doesn’t have any more visibility of your code than another developer would if he or she were consuming it.

All of this boils down to say, if it’s observable, it’s testable. Which means, the easiest and most natural code to test is public code.

Public over private (and internal)

So should everything be public instead of private or internal? Certainly not.

Object-oriented programming strives for data-hiding and encapsulation, so there are reasons to keep some things non-public.

Additionally, there are certain Swift compiler optimizations (which lead to run-time optimizations) that can be gained when you mark things in your Type as final. Using the private access modifier allows the compiler to infer that it is final because it’s narrowly scoped to the current Type only. These are handy things to know, but as is always the case with optimization, avoid premature optimization by measuring first to decide if you really need them.

Whenever possible, I prefer public over the other access modifiers to help enable testing for my apps.

So when is “whenever possible”?

Public when part of a Type’s reason for existence

Obviously, properties and functions that are part of a Type’s core purpose can be marked public. My practice is to decide, “Is this function why this Type exists?”. If so, I mark it as public.

Note also that the Type itself needs to be marked public if it’s going to be visible to your unit tests.

 1// Instead of this (default --internal-- access)...
 2class MyClass {
 3    func myFunc() {
 4        // Performs something essential to why MyClass exists
 5    }
 6}
 7
 8// Make things public...
 9public class MyClass {
10    public func myFunc() {
11        // Performs something essential to why MyClass exists
12    }
13}

Transition many private components to new Type

Having many private properties and functions can be an indication that there needs to be a new Type created to encapsulate those components. I’ve heard developers talk about this situation as one that “screams, ‘New Type!’”.

If we extract out sets of related private properties and functions into a new Type, those pieces of code are the reason that Type exists, and thus should be marked public. Testing, then, becomes a matter of writing unit tests for the new Type and its public API!

Even if you just have a few private code blocks in the Type you’re trying to test, it can sometimes make your testing life easier to transition them to a new Type as public components.

If I’m really uncomfortable marking functions public in the Type where they currently exist, creating a new Type and marking them public there is usually the better alternative, and it immediately enables testing for that set of code.

Testing non-public code

As I mentioned in the beginning, it’s not good to just haphazardly go through your code and “public all the things!!”. After appropriately marking fundamental functions public and transitioning sets of private functions to new Types where they can happily live as part of that Type’s public API, there will likely be a few private or internal things left over.

How do these get tested?

Well, ideally, these are small, simple, helper functions that are only useful when called within the Type you’re working on.

If these functions produce observable results in the places where they’re called, you end up testing these non-public components implicitly, that is, by testing the things that are public.

During the course of testing some public function which calls another non-public function, that non-public function’s logic will be executed. If the outcome of that function’s execution affects the Type’s state, or the output of its public parent function, those are the things that you’d be able to write unit tests for, because those are the “observation points”, so to speak.

Wrapping up

The bottom line is: observable == testable. Just like another developer, the suite of unit tests in your test target interacts with your app’s API through the visible, observable, interface that you’ve exposed to them. The more observable your API components are, the more testable your code becomes. Which is why I prefer public over private whenever possible!

Swift Access Control – Implications for Unit Testing

Wed, 23 Jul 2014 04:04:43 +0000

If you find yourself with broken unit tests, failing to build with the error, “Use of unresolved identifier…”, you’re not alone!

Unit Tests and Swift Access Control

When Swift access control came into the picture, we suddenly had a little more to consider. From the Apple docs:

Swift access control has three access levels:

private entities can only be accessed from within the source file where they are defined.
internal entities can be accessed anywhere within the target where they are defined.
public entities can be accessed from anywhere within the target and from any other context
that imports the current target’s module.

By default, most entities in a source file have internal access.
So given the following…

Out of the box, your unit tests are part of a separate test target
The default access control for a class is internal, (meaning that if you do not explicitly specify an access control on the class / properties / functions, they’re marked internal behind the scenes)

… we now know why the unit tests break, unless we make a few tweaks: classes marked internal are only seen within a set of specified targets and our unit tests are in a separate target that our class is not a part of by default.

Options

It seems to me that we have two options:

Change the access control on our class to public. Additionally, mark any methods we intend to test with public also.
Add the class(es) you want to be able to write unit tests for to the tests target.

Solution

I found option #2 to be the easiest to implement at first. However, it turns out that this can lead to some really obscure issues. An enlightening Twitter conversation also shed some light on the subject, and pointed to the solution of testing only publicly accessible behavior that your Types expose, rather than trying to test internal implementation. That probably deserves a blog entry of its own, but for now, I’ll leave it to say that I’d recommend not adding your .swift source files to your test target, but rather to adjust the access control modifiers of the things you want to test to public (ie, Option # 1).