
Access Control in Swift - rjsamson
https://developer.apple.com/swift/blog/?id=5
======
austinz
There's also a blog post preceding this one that talks about call-by-name-
esque semantics using "@auto_closure"; it's definitely worth a look.

------
icodestuff
It's an interesting choice, but I think I'd have rather had a sensible default
for each type category than one (internal) for everything. For instances:
public classes, public enums, private or internal ivars, public methods, etc.
Just to cut down on the boilerplate.

------
voidlogic
I think its pretty unfortunate Apple chose the name used by OpenStack's Object
Storage (Swift)...

~~~
rsynnott
It's also the same name as one of their own CPU cores (the A6 CPU core was
called Swift). And another programming language. And a spacecraft. And a bird.

------
comex
Note that as seems to be in vogue these days (Go, Rust), access to a class's
methods and fields is never directly tied to code being "inside" the class;
even `private` entities are accessible from anywhere in the same source file.
I guess this is a good thing, as it avoids awkwardness with anything
implemented as a function rather than a method, and works as a substitute for
most cases where "friend" would be acceptable coding style in C++.

~~~
klodolph
You can say it's "in vogue" these days, but C had private, public, and
internal visibility (private = declared in .c file, public = declared in
public .h file, internal = declared in private .h file). It's not just that
you can technically accomplish this in C, but people actually use this all the
time. Look at almost any library and you'll find this. Other languages have
had module and library scopes for accessibility for decades as well. It's
really an aberration that some languages make it so that data structures are
the scope for symbol accessibility. C++'s accessibility rules are just bizarre
and awkward for polyglots.

~~~
josephlord
I wrote about how it is like C [0] the other day. I should update the post
with links to the Apple blog and some of things said on the forum. Maybe
tonight.

[0] [http://blog.human-friendly.com/swift-access-controls-are-
lik...](http://blog.human-friendly.com/swift-access-controls-are-like-cs-and-
that-isnt-necessarily-a-bad-thing)

------
Dewie
It seems that they have chosen a default (internal, though I don't know how to
interpret how "most of the time" works) which is similar to the default
modifier in Java. It seems, though, that java's default modifier was maybe
ill-chosen, as private and public modifiers seem far more prevalent than no
modifier (which means that the default modifier is used) in java code.

~~~
millerm
It's like "protected" access, in Java's terms. Subclasses can't access the
default members in Java. That is why it is so rarely used. It was oddly
restrictive, and didn't seem like it made much sense in most cases. I don't
find this as a bad decision, in Swift. Since you don't normally want to expose
the internals of your classes, this was a good choice.

[http://docs.oracle.com/javase/tutorial/java/javaOO/accesscon...](http://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html)

~~~
hammerdr
I think you might have gotten it wrong?

I think it (Swift's internal/default) is more like "package-private" in Java.

It looks almost exactly like C#'s internal:

[http://msdn.microsoft.com/en-
us/library/ms173121.aspx](http://msdn.microsoft.com/en-
us/library/ms173121.aspx)

------
keyle
This language feels very unfinished... I've seen 0.8 languages being far more
polished. Maybe I'm just biased? Swift looks good though. But it's only as
good as the Cocoa framework bindings really.

~~~
g_glitch
Version numbers and alpha/beta/delta labels vary and are subjective in
practice. I've seen plenty of examples and counter-examples of version numbers
and beta labels to not put much merit toward such labels.

Yes, it is unfinished. I'd rather have Apple do what it's doing -- i.e.,
releasing Swift as a beta and changing things with feedback -- than do the
opposite, which would be keeping it closed until it was super polished as they
felt it internally.

I hate seeing this "damned if you do, damned if you don't" scenario all the
time.

(1) Pre-release for feedback, get complained at for it not being finished.

(2) Polish and release later on, get complained at for not opening it up
earlier for public feedback and testing.

Apple has clearly stated that it's pre-release, that it's not set in stone
yet, and that they're open to feedback (which they have been).

~~~
tolmasky
There's a big difference between someone's pet project language, or even an
industry leader's new language in the ether, vs. the next crowned prince of an
existing ecosystem.

Despite being backed by Google, regardless of how finished or unfinished Go
was upon release, there was no _impending pressure_ that you would someday
more or less be forced to rewrite all your existing code in it. Thus the early
adopter pros and cons were pretty clear.

This is not the case with Swift. At least if you take Apple at face value,
Swift _is_ the future of the ecosystem, which creates kind of a confusing
landscape. Whether or not you should be writing your new app in Swift is a
_hard question_. Whether you should just stand in the sidelines and not bother
until Swift is more settled is a _hard question_. Swift is simultaneously in
early adopter phase and industry requirement. As such, it is more than a
little strange (arguably bordering on irresponsible) to make such a huge
announcement when most of your own framework teams had never even seen or
tried the language. I don't think there would have been any harm in getting
_internal feedback_ from your primary consumers before drawing a line in the
sand to the general public.

~~~
wsc981

      Despite being backed by Google, regardless of how 
      finished or unfinished Go was upon release, there 
      was no impending pressure that you would someday 
      more or less be forced to rewrite all your existing
      code in it. Thus the early adopter pros and cons 
      were pretty clear. This is not the case with Swift.
    

The way I look at this issue, is that for now Swift should only be used for
pet projects and the like. Simple projects that help the developer gain
experience with the language.

------
jackjeff
Anybody else missing "protected" access? Looking at the semantics of "private"
I doubt it's coming...

~~~
bluerobotcat
The default "internal" access mode is similar to "protected". It's less
granular, but that's to be expected since Swift does not (yet?) allow
partitioning of a single app or library into different namespaces.

~~~
mimighost
internel looks more like the default package scope in Java

~~~
bluerobotcat
Ah, shoot, you're right. That's what I was thinking about. It's been a long
while since I actively used Java.

------
fjcaetano
Finally! If they implement multiple inheritance I think I'll have a nerdgasm!

~~~
wyager
>If they implement multiple inheritance I think I'll have a nerdgasm!

Honest question: Why would you ever want to use multiple inheritance? It seems
like an awful design pattern.

I mean, in C++, you basically just end up with a more confusing equivalent to
Java interfaces.

~~~
jackjeff
Here's the canonical example I used to quote for multiple inheritance:
"Implementing the design pattern observer".

You basically want to add public methods addEventListener(),
removeEventListener() and a protected fireEvent() method. In Java you have no
problem inheriting the interface for these methods. However you want to
manually re-implement the damn implementation in each class that vends
interface. I can't remember how many times I wrote these...

In C++ with multiple inheritance you can inherit both the interface and
implementation, and you're done. It is one step further than Java interfaces.

These days, I don't use that so much and I would not miss multiple
inheritance. I prefer to implement the design pattern observer through signals
(boost::signal in C++, custom classes in JavaScript/TypeScript). C# delegates
provide a good solution for this problem too.

I have not touched Java since 1.4, so maybe there is a more elegant way to
solve this now...

~~~
danieldk
_You basically want to add public methods addEventListener(),
removeEventListener() and a protected fireEvent() method. In Java you have no
problem inheriting the interface for these methods. However you want to
manually re-implement the damn implementation in each class that vends
interface. I can 't remember how many times I wrote these..._

Why? Just use composition and delegate addEventListener() and
removeEventListener() to the member implementing the logic?

~~~
voyou
That's a good idea. And as that's a common pattern, you could allow the
programmer to specify that the compiler should automatically implement this
delegation. You could call this feature something like, I don't know,
"multiple inheritance".

~~~
danieldk
Then you don't understand composition. I can pass the actual implementation in
the constructor or via dependency injection. With multiple inheritance, your
class is restricted to one implementation. Moreover, it couples the class with
the internals of observables, rather than using simple interfaces, which
composition provides.

