zpasternack
zpasternack

Reputation: 17898

Data encapsulation in Swift

I've read the entire Swift book, and watched all the WWDC videos (all of which I heartily recommend). One thing I'm worried about is data encapsulation.

Consider the following (entirely contrived) example:

class Stack<T>
{
    var items : T[] = []

    func push( newItem: T ) {
        items.insert( newItem, atIndex: 0 )
    }

    func pop() -> T? {
        if items.count == 0 {
            return nil;
        }

        return items.removeAtIndex( 0 );
    }
}

This class implements a stack, and implements it using an Array. Problem is, items (like all properties in Swift) is public, so nothing is preventing anyone from directly accessing (or even mutating) it separate from the public API. As a curmudgeonly old C++ guy, this makes me very grumpy.

I see people bemoaning the lack of access modifiers, and while I agree they would directly address the issue (and I hear rumors that they might be implemented Soon (TM) ), I wonder what some strategies for data hiding would be in their absence.

Have I missed something, or is this simply an omission in the language?

Upvotes: 6

Views: 5408

Answers (3)

PakitoV
PakitoV

Reputation: 2498

Updated answer for future reference.

From Apple's documentation:

Access Levels

Swift provides three different access levels for entities within your code. These access levels are relative to the source file in which an entity is defined, and also relative to the module that source file belongs to.

Public access enables entities to be used within any source file from their defining module, and also in a source file from another module that imports the defining module. You typically use public access when specifying the public interface to a framework.

Internal access enables entities to be used within any source file from their defining module, but not in any source file outside of that module. You typically use internal access when defining an app’s or a framework’s internal structure.

Private access restricts the use of an entity to its own defining source file. Use private access to hide the implementation details of a specific piece of functionality. Public access is the highest (least restrictive) access level and private access is the lowest (or most restrictive) access level.

Upvotes: 4

Fabrizio Bartolomucci
Fabrizio Bartolomucci

Reputation: 4958

As a matter of fact I was delighted Swift finally adopted static typing so conforming to the theory for code with optimal OO properties, still the fall of the headers breaks the very meniang of Object Orienting programming, namely encapsulation. A way out would be like for Eiffel to automaticaly extract the headers but without specifying which are the public interfaces and which the private ones, it would be wortheless. I am really lambasted at this move of Apple's.

Upvotes: 0

user1059264
user1059264

Reputation:

It's simply missing at the moment. Greg Parker has explicitly stated (in this dev forums thread) that visibility modifiers are coming.

Given that there aren't headers, the standard Objective-C tricks won't work, and I can't think of another trick to limit visibility that doesn't involve lots of bending over backwards. Since the language feature has been promised I'm not sure it's worth any big investment.

On the bright side since this feature is in flux, now is a great time to file a radar and influence how it turns out.

Upvotes: 6

Related Questions