Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

Just spend a bit of time to try an figure out how these “cards” work. But it is not user friendly imo. I simply don’t have the time to learn the concept and read the user manuals to try and figure out the details. (I did sign up, I did try to read “the basics”, but I am probably not nimble enough

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

> Le 1 déc. 2016 à 18:54, Gonçalo Alvarez Peixoto via swift-evolution > a écrit : > > @Aron, I did take a look at that document while developing the proposal. As > you stated, it's a little old, however the principles of access control and > their purpose remain pretty much the same. > > ".

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

@Xiaodi @Tino Apologies for my assumption that every developer already knows how to use Trello - the “lists” contain “cards” and the cards can be opened and you can add a more detailed description, comments, checklists, images, and other stuff. The thing you see in the list is just the title/headli

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

> An interesting format. Since it's a list, I'm not sure how to go about > commenting on the items already there with which I disagree. IMO, the format > doesn't lend itself to discussion. I have to agree… although I fear the major problem isn't the format, but rather the spirit: I guess tools

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

For those who are considering this topic, the existing document here is a good resource: https://github.com/apple/swift/blob/master/docs/AccessControl.rst Note that "class-only" and "protected" access levels are specifically called out as non-goals for Swift, with accompanying justification. Perhap

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

An interesting format. Since it's a list, I'm not sure how to go about commenting on the items already there with which I disagree. IMO, the format doesn't lend itself to discussion. For example, _why_ do you want friend classes? By contrast, it's been said on this list that not having them is con

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

No idea if this will be useful, or if it will work, but I created a public trello board: https://trello.com/b/fmv4uV3n/swift-access-control - Pre-populated with a few of the things already mentioned. - There’s a link on the board to gain edit access. It’s possible this will be an utter dis

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

Well, that's literally what I just mentioned above. I'd be fine with getting rid of private and fileprivate. On Fri, Dec 2, 2016 at 16:30 Jonathan Hull wrote: > On Dec 2, 2016, at 2:21 PM, Xiaodi Wu wrote: > > I'm not sure why that last scenario couldn't be accommodated by > submodules. Why woul

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

> On Dec 2, 2016, at 2:21 PM, Xiaodi Wu wrote: > > I'm not sure why that last scenario couldn't be accommodated by submodules. > Why wouldn't you put those two specific submodules in the same parent > submodule? Why even have private and fileprivate? Why not just make everything internal? S

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

I'm not sure why that last scenario couldn't be accommodated by submodules. Why wouldn't you put those two specific submodules in the same parent submodule? On Fri, Dec 2, 2016 at 15:35 Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > Assuming that this is true (I tend to ag

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

Assuming that this is true (I tend to agree), why do we need any extra syntax at all? Couldn’t we just make everything accessible to extensions? Alternatively, if we do want to hide some things from extensions by default (to prevent accidental use), I had a proposal a while back which had a ver

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

Sent from my iPhone > On 2 Dec 2016, at 17:18, Daniel Leping via swift-evolution > wrote: > > +1 for a warts collection > > -1 for abstract classes, though. There is a good potential to pull off the > same thing with protocols. Take a look at Scala traits. Make protocols a bit > more power

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

True story, here is a good blog post about that topic: Protocol Oriented Programming is Not a Silver Bullet --  Adrian Zubarev Sent with Airmail Am 2. Dezember 2016 um 20:51:20, Goffredo Marocchi (pana...@gmail.com) schrieb:  is a POP language right? So lets focus on fixing and improving pro

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

It seems a bit like a false equivalency as notation in music is more convention on how to interpret the notes rather than something actively part of the creative process potentially. All the programming languages are essentially reducible to if and recursion... should we just give up and move i

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

I think Swift 4 is the last chance for something such as abstract methods and classes and we should really take another look at them soon. They are not a silver bullet, but still a very good tool to have in your tool belt. Sent from my iPhone > On 2 Dec 2016, at 15:36, Jeremy Pereira via swift-

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

is a POP language right? So lets focus on fixing and improving protocols. :) We should start with open/public protocol. No, this is not a POP language only, OOP is neither discourage nor unwelcome and it is a first class citizen. Telling people there are better ways in some / many scenarios an

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

> On 2 Dec 2016, at 15:44, Benjamin Spratling wrote: > > I see where you're going with that. So it's an artifact from Java and C++, > too? :) > > I was recently doing a review of music notation, and one of the problems is > that it has multiple ways of doing exactly the same thing. Anyone

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

+1 for a warts collection -1 for abstract classes, though. There is a good potential to pull off the same thing with protocols. Take a look at Scala traits. Make protocols a bit more powerful and we get the same mechanics. On Fri, 2 Dec 2016 at 19:03 Tino Heth via swift-evolution < swift-evolutio

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

Looks like it's time for a better tool to collect opinions (at least for this thread)… is there anyone who has a possible solution at his disposal? (I wouldn't mind preparing something, but starting collaboration is hard, so I'd rather join someone with enough confidence ;-) Personally, I'd pref

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

A catalog of warts would definitely be a very important thing to continue this discussion. Keep in mind that one option that has been suggested on this list, and which has received some positive thoughts from some core team members, is to consider whether fileprivate vs. private is carrying its ow

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

I think at this point we really need to build a concrete catalog of "warts" that cause implementation details to leak out of a module to consumers of a module (by extension submodule). I think that is the first things that should be looked at when considering making any changes to the access contro

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

+1 for Discourse and polls  --  Adrian Zubarev Sent with Airmail Am 2. Dezember 2016 um 16:51:22, Tino Heth (2...@gmx.de) schrieb: I'm not sure if there is a single thing in the universe where really everybody agrees on — right now, there is nothing more than a small group that has a vague agre

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

Abstract classes would introduce even more awkward complexity to the current metatype model of Swift (so do I believe). Abstract classes are like existentials right? ATM we’ve got the problem with T.Type vs. T.Protocol which is clumsy. Abstract classes might introduce T.Class or even used as T.P

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

> Well, anyways, with Swift 3 it no longer is as simple as it is in Obj-C. New > modifiers were introduced by request. I feel it's good and means everybody > agrees Obj-C modifiers aren't sufficient for Swift. Well… no ;-) I'm not sure if there is a single thing in the universe where really every

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

I see where you're going with that. So it's an artifact from Java and C++, too? :) I was recently doing a review of music notation, and one of the problems is that it has multiple ways of doing exactly the same thing. Anyone trying to read a given piece of music has to learn all of them, mak

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

> On 2 Dec 2016, at 14:07, Benjamin Spratling via swift-evolution > wrote: > > I agree that there is a major problem with “subclasses must override these > methods”. We have no capability to describe this in Swift, and frankly, it > feels like something that ought to be enforced. It’s almos

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

I agree that there is a major problem with “subclasses must override these methods”. We have no capability to describe this in Swift, and frankly, it feels like something that ought to be enforced. It’s almost like we were really asked to conform to a protocol, but the protocol was a class. M

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

Folks, it really gets intense (and I really like it, while not being satisfied with current system) and looks like reconsidering from scratch. To make the further communication productive let's first bring the bigger picture into context. Let's bring some history first. Initially Swift adapted th

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

"The thing is, typeprivate cannot replace fileprivate, just because fileprivate adds internal visibility to other scopes inside the same file and does not restrict it to the same type. And I really love that aspect of Swift. :)" While I do see the advantages in exposing members within the same fil

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

IMO there is no need for something like typepublic to even exist, but in theory it would be something like where a subclass has more visibility of the internal stuff of its super type. I’m just saying that someone will want this, because that person might thing that typepublic and typeprivate wo

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

@Adrian I do agree with you when you state "But instead of introducing even more access modifiers we probably should fix some of the existing ones". As I mentioned in the proposal, typeprivate level could somehow replace fileprivate which, in my opinion, falls short in promoting good design practi

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

There is some really deep talk going on here again. But instead of introducing even more access modifiers we probably should fix some of the existing ones. Don’t get me wrong, I understand what the authors of the proposal are trying to introduce to the language, but even if such a proposal would

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

> And the funny thing is, we don’t actually _need_ access control levels. That is true (but actually, there isn't much that is really needed ;-) [Months ago, I've been thinking of proposing a system that is backed by private/public key cryptography — just to make fun of some overstated plans ;-)

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

And the funny thing is, we don’t actually _need_ access control levels. The only purpose of access control is to enhance security/reliability by imposing restrictions on other programmers (API users). It seems to me that in almost all discussions the arguments are mostly backwards: i.e. formula

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

@Brandon *Is anyone starting to think the current access control model will become more burdensome over time?* *People will want to add and subtract to it for years to come...which tells me it's not very flexible. I'm beginning to feel like it is an old style model trying to fit into a modern lan

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

> This keeps leading me back to having submodules or creating modules on > demand. I think that would open up this system to great complexity. I meant "flexibility"...not complexity. Freudian slip? 😂 Brandon ___ swift-evolution mailing list swift-ev

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

Is anyone starting to think the current access control model will become more burdensome over time? People will want to add and subtract to it for years to come...which tells me it's not very flexible. I'm beginning to feel like it is an old style model trying to fit into a modern language. F

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

@Aron, I did take a look at that document while developing the proposal. As you stated, it's a little old, however the principles of access control and their purpose remain pretty much the same. ".keep private details of a class hidden from the rest of the app .keep interna details of a framework

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

Hi, Am 2016-12-01 11:08, schrieb Álvaro Monteiro via swift-evolution: > - Typeprivate would allow to abandon the odd fileprivate. Access level > would be constrained to swift constructs (structs, classes and > extensions) and not to a compiler artifact (file). Files are not compiler artifacts but

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

We really need a place for discussions that apply to deferred issues. Some previous suggestions from myself and others have been: - A Discourse board - Tag emails [4.1] (or something else) if they are known to relate to deferred proposals. - A ‘deferred’ directory for complete proposal

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

@Tino: Regarding the following statement - "Even if there was a change of mind, fileprivate is still needed for essential things like implementing Equatable.” How exactly is that so? Am I missing something? > > - Typeprivate would allow to abandon the odd fileprivate. Access level > > would be c

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

I know it is a little old, but this is a nice read about the motivation for Swift's original access modifiers and why 'Protected' was not defined as an access level. https://developer.apple.com/swift/blog/?id=11 I think the point here is that ac

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

This discussion has been had on this list several times already. Using a name other than fileprivate, in particular, was part of the original discussion and the core team selected the current spelling. As Tino mentioned, submodules are a topic that the community has already expressed some interest

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

@Daniel, agree. Sent from my iPhone. Erroneous words are a feature, not a typo. > On 1 Dec 2016, at 14:23, Daniel Leping wrote: > > Gonçalo, I can suggest a bit different API to avoid clashing. Something like: > > private (file, set) > > Instead of: > > private (file) (set) > > Looks easier

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

Gonçalo, I can suggest a bit different API to avoid clashing. Something like: private (file, set) Instead of: private (file) (set) Looks easier to me as it poses a possibility just to list the attributes in a pretty much standard way. On Thu, 1 Dec 2016 at 16:15 Gonçalo Alvarez Peixoto via swi

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

*@Daniel* I am very fond of your idea, as I believe it add extra flexibility to this solution, as Álvaro mentioned. My only concern is somehow related to semantics. Should we add the extra scope detail as you suggest, then it could clash with the current way of setting a setter as private or filepr

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

Let's add "private (ancestors)" on top. As a framework developer I really miss it. On Thu, 1 Dec 2016 at 15:34 Tino Heth via swift-evolution < swift-evolution@swift.org> wrote: > > @Tino: Regarding the following statement - "Even if there was a change of > mind, fileprivate is still needed for es

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

> @Tino: Regarding the following statement - "Even if there was a change of > mind, fileprivate is still needed for essential things like implementing > Equatable.” > How exactly is that so? Am I missing something? class Eq: Equatable { private var value = 0 } func ==(lhs: Eq, rhs: Eq)

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

@Tino: Regarding the following statement - "Even if there was a change of mind, fileprivate is still needed for essential things like implementing Equatable.” How exactly is that so? Am I missing something? > > - Typeprivate would allow to abandon the odd fileprivate. Access level > > would be c

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

> private(scope) decl > > Where scope is optional and defaults to full private. Can take "file" and > "type" values. I.e: > > private (file) var i = 1 > private func a() > private (type) func b() > > This way we can have a very fine grained access levels and maintain a better > structure. Wh

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

@Daniel: Very good idea because and it makes access control much more flexible. @Tino: Couldn't agree with you more about the usage of "swifty". I think it's applicable here because communication is something that everyone agrees is a essential in swift and access control is one of the many ways

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

Exactly. Totally agree Tino. Sent from my iPhone. Erroneous words are a feature, not a typo. > On 1 Dec 2016, at 09:31, Tino Heth <2...@gmx.de> wrote: > > >> It also means that anybody who want to access your private var will just >> have to write an extension to expose it. > imho this is wron

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

> - Typeprivate would allow to abandon the odd fileprivate. Access level would > be constrained to swift constructs (structs, classes and extensions) and not > to a compiler artifact (file). Actually, imho fileprivate isn't odd or "unswift"* — it's one of the three original levels, which all rel

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

How about making things more organized and move to syntax like this: private(scope) decl Where scope is optional and defaults to full private. Can take "file" and "type" values. I.e: private (file) var i = 1 private func a() private (type) func b() This way we can have a very fine grained acces

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

I think the idea behind this proposal is quite the contrary. It is about conveying the right message through the use of an expressive access control that addresses common use cases and leaves behind fileprivate which IMHO is a C inherited way of thinking. Let me try to be clear: - Private would w

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

> It also means that anybody who want to access your private var will just have > to write an extension to expose it. imho this is wrong thinking: Access control is no tool to offer real "protection" — it can't stop someone who wants to break a system. Especially in the world of open source, it

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

Still better than exposing to any subclass implementation or direct external access IMHO. Sent from my iPhone. Erroneous words are a feature, not a typo. > On 1 Dec 2016, at 07:40, Jean-Daniel wrote: > > If you add a typeprivate accessor, it means you expose your internal details > to all ex

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

> Le 30 nov. 2016 à 16:00, João David via swift-evolution > a écrit : > > Definetely the access control topic is highly contestable in the Swift scene > but nevertheless I really strive for more flexibility in terms of how can I > decouple and decompose my code arch among several source files

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

Hello, Tino! Thanks for your feedback. I do suggest an alternative, in which *typeprivate *replaces file private, since I believe that having the scope of a member limited by file scope does does fall short in fitting a language design purpose, as file is a compiler related construct which could,

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

Hey, Robert! Thanks for your feedback. I do believe that it is a common practice, and a good one as well, to have your code broken down into separate extensions, either for improving code readability by reducing the size of the implementation file, as well as creating context for feature developm

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

As you pointed out, Swift already has quite a lot access levels… Comparing the usefulness, "typeprivate" would clearly win over (Swift 3) "private" for me — but it adds a "new dimension" to the game, and I guess this will be a dealbreaker: Should it be possible to access typeprivate data from ano

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

Is that a particularly common case? I haven’t written code that needs access patterns like this and it strikes me as strange that anything you’re willing to expose to extensions scattered throughout your codebase you’d also prefer not to export throughout a module that you have complete control

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

Robert, Thanks for your feedback. However, I tend to disagree with you. *"The proposal, as it stands, does nothing to indicate how this is much different from internal - all examples given would trivially be solved by internal members."* This proposal aims at covering all of the cases in which y

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

The proposal, as it stands, does nothing to indicate how this is much different from internal - all examples given would trivially be solved by internal members. I don’t think we need finer-grained access control to address this, I think we need extensions, at least in the same file as their pa