Access control below public [not `protected`]

I din’t say it was superiour. I currently try to understand the problem.

But my methology to only use accessor and provide a api to the internal representation is state of the art since Small-talk’s days. It’s basic oop design :confused:

Isn't that already made sure by only exporting public from any module?

I think what Charles is trying to say is that on Apple platforms by today open and public does not exist, except for modules and frameforks, all App targets are suffering by this problem where internal becomes the top most access modifier and private takes over it’s role. private is meant to be, well private and no other types should be able to touch it no matter of the public or internal API, hence the title of this thread.

1 Like

Exactly. In an application target, internal essentially is public. And without something in between, you can’t follow that basic oop design you describe, unless you stuff everything into massive, cumbersome behemoth source files.

It has nothing to do with whether your classes use accessors or not; that’s a non-sequitur, like responding to someone taking a position on whether red or white wine should be paired with a particular dish, by arguing about the shape of the glass it should be poured in. It’s an orthogonal issue.

2 Likes

So we are not talking about library code? Was under the impression access control was only useful for frameworks etc. I have never felt a reason to partition away pure application code from myself or my team. Perhaps that is the thing that hinders me understanding the problem. Hmm.

Guess I need to sleep over this.

It’s helpful for library code as well. Because unless you have a separate framework for every single view/class/type, there are going to be parts of your framework that don’t need to know about other parts. Take AppKit, for instance. Does NSTableView need to know how the internals of NSSavePanel work? Probably not. Is all of AppKit developed by the same person, who has the public interfaces of all the other AppKit classes memorized so s/he can be sure never to accidentally call internal NSTableView methods that autocomplete brought up when putting a table view inside an NSSavePanel? I’m gonna say no.

2 Likes

Guess I have done to much Python to understand where the problem lies with framework parts having internal access to all the framework’s components :slight_smile:

Like many others, I really have no intention of weighing in on this topic. However, I am not sure where people are getting this notion that Swift is “style-agnostic” or “non-opinionated.”

As Chris Lattner has stated previously: “We intentionally want Swift to have a common ‘center of gravity’ and be an ‘opinionated’ language, rather than fall to the ‘design by committee’ approach that leads to a watered-down design.”

The current state of access control reflects Swift’s center of gravity after extensive discussion. To the extent that it does promote a certain style of coding, the language deliberately takes a non-neutral position.

7 Likes

Personally, I don’t have this problem. For me, object composition is the answer. If the object needs to be split into multiple files to be readable, it’s … well a mega object. Still, I’m all for removal of “fileprivate”. :slight_smile:

Hi @xwu , would you mind sharing the source of that quote, it would be good to know in which context Chris said that.

Personally I get the notion that Swift is not opinionated by following the evolution of Swift. Aspriational quotes are nice, but can you give some examples of opinionated decisions made since Swift Evolution started?

To me Swift Evolution is the definition of "design by committee". Even worse actually, since it is a committee of enthusiasts, not a committee of experts (as in e.g. Haskell).

1 Like

Just to make things clear, I’ll re-read the threads you linked in your post and summarize the points that has been made, but that will take a few days to do so (currently super busy with work).

It is seeded by enthusiasts, but decided by experts. Remember that the Core Team always has the last word in these regards.

1 Like

I have actually tried to pitch this idea: Proposal: Eliminate the Review phase

In practice the Core Team has more of a veto power, the decisions are also made by enthusiasts.

Ah, well, fair enough.

Still, I think it doesn’t inherit all of the bad traits of a design by commitee (I’ll use DbC now bc it’s too long) approach. The veto of the Core Team and their ability to focus the Review process on what’s most relevant for the current step in the language’s roadmap are clear advantages over DbC.

DbC is a low bar, though. So we should aspire to be even better than that.

I think the SE process is good in general, but the greatest weakness that I see at least is this: lack of a greater-picture design. Some things are hard to get right with a fast-paced process like SE. When you have lots of moving parts in a problem, natural SE can’t effectively fix it.

I think that’s how we got into the access control problems we see today. The system is dissonant with the rest of the language, and that is a consequence of the pace of SE. How can this be fixed? Well… slowly, I guess. You have to look not only at access control, but also at a possible future submodule system (whatever that means as Jordan Rose pointed out in his recent post), at what kinds of SW architecture Swift encourages (use of structs, for example), at the extensions system and what’s coming for that in the future, and so on.

Problems like these are not something that can be just fixed with a proposal, and we should recognize that.

I think access control is inherently at odds with any DbC approach. The entire purpose of AC is to impose discipline on developers. While there are optimizations which can be done when there is limited visibility for a type or property, that’s not why app developers want it to exist. Given that imposition of discipline is inherently subjective, you’re not going to find the “One True Path” no matter how much time is spent looking.

Some simple forums searching: [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

1 Like

@DevAndArtist I love this (old) proposal! Any news? :smiley: What are the reasons for not having proper access modifiers in place in Swift 5?

I would really love to be able to declare my (stored)properties as private and still be able to access them inside extensions in other files. Possibly also something specific for classes and inherited but not as important.

Ugh, had to read a two-year old thread from scratch for a single new message that should have been in a new thread.

That said, is guess the solution wouldn’t be sub-modules, but a “cluster” access level that’s between “fileprivate” and “internal.” But each file in the module would have to declare which cluster it belongs to. (Plus a default void-cluster when no cluster name is given.)

1 Like

@Sajjon hi there. Well this thread was a discussion thread, not really a pitch so there is no formal proposal here buz only a back an forth of different ideas. Even though I would love to have a bit more flexibilities in the access control area which wouldn’t divide the community into multiple camps, I’m not sure if we can fix it unless we decide to do a massive source breaking change at some point.

All these existing issues and the current testability support made me change my mind a little. I no longer use private or fileprivate in any of my code. The only access modifiers I need are open (I wish it had better consistency with protocols), public and finally internal (but mostly implicitly). To signal (type/file)private access I fall back to a _ prefix.