Re: [swift-evolution] [Proposal] Protected Access Level

[Callionica (Swift) via swift-evolution]

It might be worth being more specific with your comparison between the
"lock and key" access control I described and the other techniques
described in this thread. Given that the designers of Swift were familiar
with protected access level from other languages and deliberately chose to
exclude it, it seems likely that you'll need to give some detailed pros and
cons to get a protected access level accepted I think.

I don't personally have an opinion on whether protected is a compelling
addition to the Swift language. It's in some of the languages that I use
and not others. I use it extensively where available, but it's not a
compelling enough feature on its own to make me choose one language over
another. I just wanted to make sure that people were aware of some other
techniques available for implementation hiding that are available in the
language today. (There are many more than just the one I presented if
you're willing to take a small runtime cost).

-- Callionica

On Sun, May 29, 2016 at 10:59 PM, Rod Brown 
wrote:

> I have to agree with Charlie Monroe that while this is doable, it's clear
> this is a workaround to a problem, not a viable long term language solution.
>
> - Rod
>
>
>
> Sent from my iPhone
> On 30 May 2016, at 2:49 PM, Callionica (Swift) <
> swift-callion...@callionica.com> wrote:
>
> I've written up how to provide protected access control for Swift code
> today here:
>
> http://www.callionica.com/developer/#swift-protected
>
> No compiler changes necessary for this technique and it distinguishes
> between methods that can only be overridden and methods that can be both
> called and overridden.
> ​
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[Charles Srstka via swift-evolution]

> On May 30, 2016, at 2:02 PM, Tino Heth <2...@gmx.de> wrote:
> 
>> The purpose of access control isn’t really to keep out malicious users, 
>> though, it’s to prevent accidental misuse and clarify the interface.
> mh, I would call this a "documenting intend" ;-)

If you get the method as an autocomplete, you won’t see the documentation 
telling you not to use it.

>> One nice vector for accidental misuse is autocomplete. Even if 
>> layoutSubviews() has a great big // DON’T USE!!! in the documentation, it’s 
>> possible that someone is trying to remember the name of the API they need to 
>> use to tell the OS something needs to update its layout, so they type 
>> “layout” into the code editor, and lo and behold! Here’s something called 
>> layoutSubviews() that sounds like the sort of thing we want. And so it goes. 
>> A protected modifier in the language would prevent things like this.
> true — but even subclasses shouldn't call layoutSubviews unregulated, so I 
> think this is a flawed example for the usefulness of protected.


This is why I prefer fileprivate(call) over protected.

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[Tino Heth via swift-evolution]

> The purpose of access control isn’t really to keep out malicious users, 
> though, it’s to prevent accidental misuse and clarify the interface.
mh, I would call this a "documenting intend" ;-)

> One nice vector for accidental misuse is autocomplete. Even if 
> layoutSubviews() has a great big // DON’T USE!!! in the documentation, it’s 
> possible that someone is trying to remember the name of the API they need to 
> use to tell the OS something needs to update its layout, so they type 
> “layout” into the code editor, and lo and behold! Here’s something called 
> layoutSubviews() that sounds like the sort of thing we want. And so it goes. 
> A protected modifier in the language would prevent things like this.
true — but even subclasses shouldn't call layoutSubviews unregulated, so I 
think this is a flawed example for the usefulness of protected.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[Charles Srstka via swift-evolution]

> On May 30, 2016, at 11:23 AM, Tino Heth <2...@gmx.de> wrote:
> 
>> Couldn’t you use the same reasoning to claim there shouldn’t be access 
>> control at all? Just add documention on methods you want to mark private 
>> telling users of the library not to call them!
> 
> I guess you are making fun, but actually, good old Objective-C messaging 
> works just that way:
> You can call all those dangerous and forbidden private methods easily...
> Writing special comments is just one way to document APIs; having no 
> (official) documentation at all is documentation as well ("don't use this!").
> 
> Most technical limitations can be cracked by skilled hackers (working around 
> "protected" is especially easy), so I really think that (for example) 
> declaring a method "final" says "I don't want this to be changed in a 
> subclass" in the first place, and the compiler error that is triggered when 
> you try to break the limitation is little more but a remainder.
> 
> Enforcing limitations using hacks causes confusion, so I would never use such 
> tricks in production code.

The purpose of access control isn’t really to keep out malicious users, though, 
it’s to prevent accidental misuse and clarify the interface.

One nice vector for accidental misuse is autocomplete. Even if layoutSubviews() 
has a great big // DON’T USE!!! in the documentation, it’s possible that 
someone is trying to remember the name of the API they need to use to tell the 
OS something needs to update its layout, so they type “layout” into the code 
editor, and lo and behold! Here’s something called layoutSubviews() that sounds 
like the sort of thing we want. And so it goes. A protected modifier in the 
language would prevent things like this.

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[L Mihalkovic via swift-evolution]

> On May 30, 2016, at 2:46 AM, Rod Brown via swift-evolution 
>  wrote:
> 
> Brent,
> 
> You make a very good point about the fact internal is not necessarily the 
> same as subclass, something I hadn’t considered.
> 
> I think that the level of exposure these APIs then get - ultimately Public 
> within frameworks - is too unrestricted. At least in Objective-C, we can vet 
> the headers to break classes into separate sections where we don’t disclose 
> certain headers to show something by default. Can we think of a way to allow 
> opt-in access?
> 
> This ultimately gets into one of my major sore points with Swift: Framework 
> Generated Headers suck. The Framework story for Swift seems shockingly ill 
> conceived at this time. I could never imagine Apple shipping a framework with 
> the current Framework setup… but I’m going into the weeds…

most Objc code out there is appalling when it comes to design enforcing clean 
API boundaries. It stems directly from the lack of scopes in the language to 
hide things. Over the years the language was drastically improved, but 99% of 
the code on github is still written like 20 years ago (minus the @synthesize). 
Unfortunately for swift, there is not much more choices than to have Framework 
= Module. A possible future improvement might be to have Framework = n-Module, 
but that is somehow doable if you make a multi dylib framework. The cost of 
creating several Swift modules inside a single framework is not light today 
(there would have to be one more level of section name mangling inside the 
dylib, something like  

____sectionA 
____sectionB 
____sectionC 

____sectionA 
____sectionB 
____sectionC 

where / are the names of the modules/namespaces sharing space inside a 
single dylib, compared to today's

__sectionA 
__sectionB 
__sectionC 

all things considered, it may not be that stupid… dunno it is would make lookup 
faster or slower if the sections were smaller. It would be backward compatible… 
because the current sections could be kept for the top level Module… hm… 
might be workable.

> 
> -Rod
> 
> 
>> On 30 May 2016, at 10:03 AM, Brent Royal-Gordon  
>> wrote:
>> 
>>> 1. Methods and properties that only subclasses must access, but other code 
>>> has no business updating. An example of this UIGestureRecognizer. State 
>>> machine type access is something where external items should not access, 
>>> but internal state may require the rights to update.
>> 
>> But again, "external" does not necessarily mean "non-subclass", and 
>> "internal" does not necessarily mean "subclass". A particular subclass might 
>> not require access, and a helper type/function might require access.
>> 
>> This insight—that the type graph doesn't always reflect the boundaries of 
>> concerns—is the very basis of Swift's current access control design. It's 
>> the reason why `private` (soon to become `fileprivate`) doesn't grant 
>> visibility to extensions on the same type in different files, but *does* 
>> grant it to extensions on different types in the same file. This is an 
>> important innovation in Swift's access control design, and we shouldn't 
>> ignore it when we're thinking about `protected`.
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[Tino Heth via swift-evolution]

> Couldn’t you use the same reasoning to claim there shouldn’t be access 
> control at all? Just add documention on methods you want to mark private 
> telling users of the library not to call them!

I guess you are making fun, but actually, good old Objective-C messaging works 
just that way:
You can call all those dangerous and forbidden private methods easily...
Writing special comments is just one way to document APIs; having no (official) 
documentation at all is documentation as well ("don't use this!").

Most technical limitations can be cracked by skilled hackers (working around 
"protected" is especially easy), so I really think that (for example) declaring 
a method "final" says "I don't want this to be changed in a subclass" in the 
first place, and the compiler error that is triggered when you try to break the 
limitation is little more but a remainder.

Enforcing limitations using hacks causes confusion, so I would never use such 
tricks in production code.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[Jonathan Hull via swift-evolution]

I kind of want something like protected for protocols, but not necessarily 
protected as it is implemented in other languages.

I often have a few low-level methods in a protocol which the higher level 
methods in protocol extensions use to do their work.  Occasionally, I need to 
guarantee a piece of information in the protocol, but I really don’t want to 
expose it to everyone.  Right now I do, and then put a warning not to call it 
directly.

What I would like, is a way to mark a method as needing to be implemented, but 
allow that implementation to have a lower access level than the protocol itself 
(e.g. the method is private, but the protocol is public).  I also want 
extensions to the protocol to be able to see/access those methods.

I don’t know what form this would take. There are lots of options:
- Mark the methods as “hidden” or some other keyword in the protocol
- Treat it like private(set) and allow different access levels to be set when 
it is accessed from extensions (e.g. a method might be private, but set to 
internal for extensions… thus you can call the method from within extensions in 
the module, but not from arbitrary code or extensions outside the module)
- Something I haven’t thought of.

I kind of like the idea of being able to set a specific access level for what 
extensions see in general.  

Thanks,
Jon
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[Charles Srstka via swift-evolution]

> On May 30, 2016, at 3:42 AM, Tino Heth via swift-evolution 
>  wrote:
> 
>> I can't reply directly to all the points in this thread, but I will just say 
>> that there are ways of emulating protected in the language as it exists 
>> today:
>> 
>> If the goal is to have functions that can be overridden by subclasses 
>> without being called by external classes, you can create a parameter of a 
>> public type with a private initializer and use it in all "protected" member 
>> functions. No external code will be able to call such functions because they 
>> cannot create an argument of the correct type.
> As others stated before:
> I agree it's a cool little hack, but a hack none the less — and imho it isn't 
> useful in real life.
> The focus should be documenting intend ("this method should be used in a 
> certain way"). Creating clever countermeasures to stop users of a library to 
> enforce limitations is imho the wrong way.

Couldn’t you use the same reasoning to claim there shouldn’t be access control 
at all? Just add documention on methods you want to mark private telling users 
of the library not to call them!

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[Tino Heth via swift-evolution]

> 
> I can't reply directly to all the points in this thread, but I will just say 
> that there are ways of emulating protected in the language as it exists today:
> 
> If the goal is to have functions that can be overridden by subclasses without 
> being called by external classes, you can create a parameter of a public type 
> with a private initializer and use it in all "protected" member functions. No 
> external code will be able to call such functions because they cannot create 
> an argument of the correct type.
As others stated before:
I agree it's a cool little hack, but a hack none the less — and imho it isn't 
useful in real life.
The focus should be documenting intend ("this method should be used in a 
certain way"). Creating clever countermeasures to stop users of a library to 
enforce limitations is imho the wrong way.

We could even use tools like public key cryptography to secure access to APIs — 
or is there any developer who doesn't want to deal with more certificates? ;-)


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[Charles Srstka via swift-evolution]

> On May 28, 2016, at 8:11 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> But `protected` is quite different from other access levels; it does not 
> limit the visibility of the symbols, but rather their use. And protocols face 
> the same sort of problem as classes, where certain members are essentially 
> override hooks and shouldn't be called directly outside a particular scope.
> 
> So I think we ought to allow `accesslevel(call)`, but not a plain 
> `accesslevel`:
> 
>   public fileprivate(call) func layoutSubviews()
>   internal fileprivate(call) func privateSubclassingHook()
>   public internal(set: call) var x = 20
>   internal(call) func protocolConformanceHook()
>   fileprivate(set: call) var onlyProtocolSetsThis: Int { get set }


Given that this is almost identical to the pitch I floated to the list some 
months ago, all the way down to the fileprivate(call) syntax (well, back then 
“fileprivate” was “private”, so it was private(call)), I’m +1 on this.

> On May 29, 2016, at 6:55 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> The thing is, though, the contents of the sharps drawer are *still* sharp 
> even if you're old enough to use a knife. And similarly, APIs like the 
> `state` setter are *still* dangerous even if you've subclassed 
> `UIGestureRecognizer`. To be sure, it is more likely that you'll *need* to 
> set `state`, but it's still not something you should do carelessly or without 
> understanding the consequences.


This, though, reads like “The 17-year-old might cut himself with a knife, even 
though he *needs* the knives to help with the cooking. So, let’s give knives to 
the newborn!”

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[Pyry Jahkola via swift-evolution]

That's a cool hack! For a lighter way to distinguish overridable methods that 
one shouldn't ordinarily call, did anyone consider approximating "protected" 
(or as called in Objective-C speak, "private extension") methods with public 
class methods?

public class UIView {
public class func _layoutSubviews(_ view: UIView)
}

This way, they become overridable, won't show up in the editor auto completion 
list for a given instance, and can be called… but definitely make you think 
twice before you do!

— Pyry

> Callionica (Swift) via swift-evolution  kirjoitti 
> 30.5.2016 kello 7.49:
> 
> I've written up how to provide protected access control for Swift code today 
> here:
> 
> http://www.callionica.com/developer/#swift-protected
> 
> No compiler changes necessary for this technique and it distinguishes between 
> methods that can only be overridden and methods that can be both called and 
> overridden.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[Rod Brown via swift-evolution]

I have to agree with Charlie Monroe that while this is doable, it's clear this 
is a workaround to a problem, not a viable long term language solution.

- Rod



Sent from my iPhone
> On 30 May 2016, at 2:49 PM, Callionica (Swift) 
>  wrote:
> 
> I've written up how to provide protected access control for Swift code today 
> here:
> 
> http://www.callionica.com/developer/#swift-protected
> 
> No compiler changes necessary for this technique and it distinguishes between 
> methods that can only be overridden and methods that can be both called and 
> overridden.
> ​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[Charlie Monroe via swift-evolution]

That's a nice workaround - but nice in a sense that that it's a hack, not a 
solution IMHO.


> On May 30, 2016, at 6:49 AM, Callionica (Swift) via swift-evolution 
>  wrote:
> 
> I've written up how to provide protected access control for Swift code today 
> here:
> 
> http://www.callionica.com/developer/#swift-protected 
> 
> 
> No compiler changes necessary for this technique and it distinguishes between 
> methods that can only be overridden and methods that can be both called and 
> overridden.
> ​
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[Thorsten Seitz via swift-evolution]

Cool!

-Thorsten 

> Am 30.05.2016 um 06:49 schrieb Callionica (Swift) via swift-evolution 
> :
> 
> I've written up how to provide protected access control for Swift code today 
> here:
> 
> http://www.callionica.com/developer/#swift-protected
> 
> No compiler changes necessary for this technique and it distinguishes between 
> methods that can only be overridden and methods that can be both called and 
> overridden.
> ​
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[Callionica (Swift) via swift-evolution]

I've written up how to provide protected access control for Swift code
today here:

http://www.callionica.com/developer/#swift-protected

No compiler changes necessary for this technique and it distinguishes
between methods that can only be overridden and methods that can be both
called and overridden.
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[Rod Brown via swift-evolution]

Brent,

You make a very good point about the fact internal is not necessarily the same 
as subclass, something I hadn’t considered.

I think that the level of exposure these APIs then get - ultimately Public 
within frameworks - is too unrestricted. At least in Objective-C, we can vet 
the headers to break classes into separate sections where we don’t disclose 
certain headers to show something by default. Can we think of a way to allow 
opt-in access?

This ultimately gets into one of my major sore points with Swift: Framework 
Generated Headers suck. The Framework story for Swift seems shockingly ill 
conceived at this time. I could never imagine Apple shipping a framework with 
the current Framework setup… but I’m going into the weeds...

-Rod


> On 30 May 2016, at 10:03 AM, Brent Royal-Gordon  
> wrote:
> 
>> 1. Methods and properties that only subclasses must access, but other code 
>> has no business updating. An example of this UIGestureRecognizer. State 
>> machine type access is something where external items should not access, but 
>> internal state may require the rights to update.
> 
> But again, "external" does not necessarily mean "non-subclass", and 
> "internal" does not necessarily mean "subclass". A particular subclass might 
> not require access, and a helper type/function might require access.
> 
> This insight—that the type graph doesn't always reflect the boundaries of 
> concerns—is the very basis of Swift's current access control design. It's the 
> reason why `private` (soon to become `fileprivate`) doesn't grant visibility 
> to extensions on the same type in different files, but *does* grant it to 
> extensions on different types in the same file. This is an important 
> innovation in Swift's access control design, and we shouldn't ignore it when 
> we're thinking about `protected`.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[Brent Royal-Gordon via swift-evolution]

> 1. Methods and properties that only subclasses must access, but other code 
> has no business updating. An example of this UIGestureRecognizer. State 
> machine type access is something where external items should not access, but 
> internal state may require the rights to update.

But again, "external" does not necessarily mean "non-subclass", and "internal" 
does not necessarily mean "subclass". A particular subclass might not require 
access, and a helper type/function might require access.

This insight—that the type graph doesn't always reflect the boundaries of 
concerns—is the very basis of Swift's current access control design. It's the 
reason why `private` (soon to become `fileprivate`) doesn't grant visibility to 
extensions on the same type in different files, but *does* grant it to 
extensions on different types in the same file. This is an important innovation 
in Swift's access control design, and we shouldn't ignore it when we're 
thinking about `protected`.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[Vanderlei Martinelli via swift-evolution]

I missed the last part when you are talking about bridging TO Objective-C,
but Rod Brown answered that very well (thanks).

-Van

On Sun, May 29, 2016 at 8:50 PM, Vanderlei Martinelli <
vmartine...@alecrim.com> wrote:

> Hi Leonardo.
>
> Thank you for your answer.
>
> I understand your point of view and I agree that it is better to look
> forward. But today we still have to deal with decades of legacy Cocoa code
> written using classes. If tomorrow a new set of Cocoa frameworks written in
> Swift using protocols appears, maybe we can forget all of this discussion.
> But OOP is very important and don't think it is the "past". I see future in
> "POP" as I see in "OOP" and I think we can have OOP and POP living in
> harmony in Swift. And since we have support to classes in Swift, I think it
> shall have a full featured support for classes.
>
> Perhaps my reaction in the last message sounds like I am overreacting when
> seen in the context of this thread. But I am programming in Swift since the
> first day it was publicly available (and I think that the first almost
> usable version to create real world apps was the 1.2). Since the old
> forums, when Swift was not yet open source, I have been insisting on
> certain improvements.
>
> About bridging member declarations from Objective-C, many of these classes
> already have separated headers with the members intended to be overrided.
> Exceptions to this rule could be "annotated" somehow. (I would like to
> mention classes that are entirely intended to be subclassed and not used as
> is in Cocoa frameworks, but this is about "abstract" access level modifier
> and not part of this proposal.)
>
> Regards,
>
> Vanderlei Martinelli
>
>
>
>
>
>
>
>
> On Sun, May 29, 2016 at 7:45 PM, Leonardo Pessoa <m...@lmpessoa.com> wrote:
>
>> Vanderlei, my point in bringing such topics to this discussion is to make
>> everyone here think if we're trying to really enhance the language within
>> its intended purpose or if we're trying to change the language into
>> something else were familiar with from other languages we work/ed with just
>> because we're used to work like that. I just started thinking about this
>> today and just cannot stop now. No intention to start a war here but I
>> think everyone should ask themselves this for every proposed change to the
>> language.
>>
>> About the topic at-hand, we have to remember Swift is bridged to
>> Objective-C, which has no protected (or abstract). How do you propose these
>> protected members be bridged should the proposal pass?
>> --
>> From: Vanderlei Martinelli via swift-evolution
>> <swift-evolution@swift.org>
>> Sent: ‎29/‎05/‎2016 06:56 PM
>> To: swift-evolution <swift-evolution@swift.org>
>> Subject: Re: [swift-evolution] [Proposal] Protected Access Level
>>
>> Thank you all for your comments. :-)
>>
>> Well... My goal is to keep the thing really simple and do not start a new
>> "OOP x POP" (or "something" x "other thing") war.
>>
>> "Protected" access level is not a new concept at all (except for the
>> Swift language), so I did not propose anything preposterous.
>>
>> Of course in the Swift of my dreams we also have "abstract" access level
>> modifier, "protected" access level, *real* "private" access level and
>> "file" access level modifier (along with many, many other things, of
>> course). But this proposal is not about this. It is only about include the
>> "protected" access level.
>>
>> There is, however, something that I need to get off my chest: I really
>> would like to have the freedom to go to the depths with protocols as well
>> with classes. I work in real apps everyday that uses Cocoa frameworks
>> (based on classes) and these apps must be shipped and I like them well
>> written. Maybe am I insane for proposing a better support for classes in
>> Swift? If so, this explains why every time I suggest better support for
>> classes in Swift there is an endless discussion and someone proclaims the
>> death of OOP and is it. OK... Maybe someday we will not have more classes
>> in Swift. Until there: the current language status is the best way to
>> handle OOP in Swift? Or is there a better way? I think there is.
>>
>>
>> Regards,
>>
>> Vanderlei Martinelli
>>
>>
>>
>>
>>>
>>>
>>
>> On Sat, May 28, 2016 at 7:52 PM, Vanderlei Martinelli <
>> vmartine...@alecrim.com&

Re: [swift-evolution] [Proposal] Protected Access Level

[Brent Royal-Gordon via swift-evolution]

> You seem to be producing a convoluted solution to create a “sharps drawer” 
> but Swift is supposed to be safe. You shouldn’t access the sharps drawer 
> there and there are better ways for us to stop you than to simply “trust” the 
> developer - it’s to do the right thing, and provide a protection level that 
> stops the access where it’s not needed: “protected”.

The thing is, though, the contents of the sharps drawer are *still* sharp even 
if you're old enough to use a knife. And similarly, APIs like the `state` 
setter are *still* dangerous even if you've subclassed `UIGestureRecognizer`. 
To be sure, it is more likely that you'll *need* to set `state`, but it's still 
not something you should do carelessly or without understanding the 
consequences.

`protected` fails to acknowledge this. It conflates the act of inheriting 
interface and implementation with the act of gaining access to dangerous 
operations. It would be  like a drawer which automatically mixed the knives in 
with the other utensils when an adult opened it.

This is a general problem with traditional OO: Inheritance bundles a whole 
bunch of separate semantics into a single operation. Obviously some of these 
are so ingrained in OO that they can't be separated; you're not going to 
separate inheritance of interface from inheritance of implementation. But the 
sharps drawer does not *have* to be part of the bundle, and there are 
compelling reasons to look for a different solution—one which fits this use 
case better, *and* simultaneously serves other use cases like non-subclassed 
types.

To give you an idea, here are a couple more potential "sharps drawers" in UIKit 
which `protected` would not serve well:

* View controller containment. There are very few view controllers which 
actually contain other view controllers; for most, these calls are a great way 
to mess things up. And yet some of these members, like `childViewControllers`, 
are definitely things you need to be able to access from outside a view 
controller, for instance to find a view controller to present an error message 
on. `protected` would expose these methods to vast amounts of code that doesn't 
need them, while hiding them from code that does.

* UIKeyInput and UITextInput methods should only be used by custom keyboards 
(either `inputView`s or keyboard extensions), but they're exposed to everybody, 
sitting right alongside methods intended for wide use. The intended clients for 
these APIs have no inheritance relationship whatsoever with the classes they 
would need to call them on, so `protected` would be of absolutely no help here.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[Vanderlei Martinelli via swift-evolution]

Hi Leonardo.

Thank you for your answer.

I understand your point of view and I agree that it is better to look
forward. But today we still have to deal with decades of legacy Cocoa code
written using classes. If tomorrow a new set of Cocoa frameworks written in
Swift using protocols appears, maybe we can forget all of this discussion.
But OOP is very important and don't think it is the "past". I see future in
"POP" as I see in "OOP" and I think we can have OOP and POP living in
harmony in Swift. And since we have support to classes in Swift, I think it
shall have a full featured support for classes.

Perhaps my reaction in the last message sounds like I am overreacting when
seen in the context of this thread. But I am programming in Swift since the
first day it was publicly available (and I think that the first almost
usable version to create real world apps was the 1.2). Since the old
forums, when Swift was not yet open source, I have been insisting on
certain improvements.

About bridging member declarations from Objective-C, many of these classes
already have separated headers with the members intended to be overrided.
Exceptions to this rule could be "annotated" somehow. (I would like to
mention classes that are entirely intended to be subclassed and not used as
is in Cocoa frameworks, but this is about "abstract" access level modifier
and not part of this proposal.)

Regards,

Vanderlei Martinelli








On Sun, May 29, 2016 at 7:45 PM, Leonardo Pessoa <m...@lmpessoa.com> wrote:

> Vanderlei, my point in bringing such topics to this discussion is to make
> everyone here think if we're trying to really enhance the language within
> its intended purpose or if we're trying to change the language into
> something else were familiar with from other languages we work/ed with just
> because we're used to work like that. I just started thinking about this
> today and just cannot stop now. No intention to start a war here but I
> think everyone should ask themselves this for every proposed change to the
> language.
>
> About the topic at-hand, we have to remember Swift is bridged to
> Objective-C, which has no protected (or abstract). How do you propose these
> protected members be bridged should the proposal pass?
> --
> From: Vanderlei Martinelli via swift-evolution <swift-evolution@swift.org>
> Sent: ‎29/‎05/‎2016 06:56 PM
> To: swift-evolution <swift-evolution@swift.org>
> Subject: Re: [swift-evolution] [Proposal] Protected Access Level
>
> Thank you all for your comments. :-)
>
> Well... My goal is to keep the thing really simple and do not start a new
> "OOP x POP" (or "something" x "other thing") war.
>
> "Protected" access level is not a new concept at all (except for the Swift
> language), so I did not propose anything preposterous.
>
> Of course in the Swift of my dreams we also have "abstract" access level
> modifier, "protected" access level, *real* "private" access level and
> "file" access level modifier (along with many, many other things, of
> course). But this proposal is not about this. It is only about include the
> "protected" access level.
>
> There is, however, something that I need to get off my chest: I really
> would like to have the freedom to go to the depths with protocols as well
> with classes. I work in real apps everyday that uses Cocoa frameworks
> (based on classes) and these apps must be shipped and I like them well
> written. Maybe am I insane for proposing a better support for classes in
> Swift? If so, this explains why every time I suggest better support for
> classes in Swift there is an endless discussion and someone proclaims the
> death of OOP and is it. OK... Maybe someday we will not have more classes
> in Swift. Until there: the current language status is the best way to
> handle OOP in Swift? Or is there a better way? I think there is.
>
>
> Regards,
>
> Vanderlei Martinelli
>
>
>
>
>>
>>
>
> On Sat, May 28, 2016 at 7:52 PM, Vanderlei Martinelli <
> vmartine...@alecrim.com> wrote:
>
>> Hello.
>>
>>
>> This is the first draft. I'd like to know your opinion about it.
>>
>> (I know that this subject could have been discussed before. If so, please
>> indicate me the correct thread to follow and interact.)
>>
>>
>> Regards,
>>
>> Vanderlei Martinelli
>>
>>
>> ---
>>
>>
>> Introduction
>>
>> Protected access level will enable entities to be used within the
>> container type and by derived types only.
>> Motivation
>>
>> Today Swift has three access levels

Re: [swift-evolution] [Proposal] Protected Access Level

[Rod Brown via swift-evolution]

I agree that we should be looking for what makes sense, not just what we’ve 
seen in other languages. That said, there seems a lot of hate for OOP in 
general that seems to be clouding people’s vision here.

I think that “protected” as a form of access control is exactly what we want: 
rights that subclasses should be allowed, but other classes should not. 
Generally they refer to internal state that only the class itself, or its 
subclass, has any business either updating or calling.

Lets drop the word “protected” for a second and actually examine the use cases 
for differing access control in classes. I think the best example of this in 
different contexts are:

1. Methods and properties that only subclasses must access, but other code has 
no business updating. An example of this UIGestureRecognizer. State machine 
type access is something where external items should not access, but internal 
state may require the rights to update.

2. Methods and properties that should be overridable, but are helper methods 
and shouldn’t be called by external methods, and perhaps shouldn’t be even 
called directly. This includes -layoutSubviews on UIView, a multitude of other 
methods in UIKit, etc. Thus I think Brent had a good point that calling a 
method might need to have different access rights to overriding it.

I think #1 shows specifically the need for access control for subclasses only, 
and thus a ‘protected’- style access control level.
I think #2 shows a need to differentiate the access rights of calling a method 
from access rights to see or override the method.

While we can find workarounds that obfuscate access, these aren’t access 
controls, they’re convoluted workarounds to avoid correcting our access control 
rules in the first place.

How do these things bridge into Objective-C?
Protected doesn’t make sense in Objective-C. You cannot subclass a Swift Class 
in Objective C, so overriding is irrelevant. I suspect the rule should be 
simple: Anything Protected should not be visible to Objective-C, much like 
private is hidden currently.

- Rod


> On 30 May 2016, at 8:45 AM, Leonardo Pessoa via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> Vanderlei, my point in bringing such topics to this discussion is to make 
> everyone here think if we're trying to really enhance the language within its 
> intended purpose or if we're trying to change the language into something 
> else were familiar with from other languages we work/ed with just because 
> we're used to work like that. I just started thinking about this today and 
> just cannot stop now. No intention to start a war here but I think everyone 
> should ask themselves this for every proposed change to the language.
> 
> About the topic at-hand, we have to remember Swift is bridged to Objective-C, 
> which has no protected (or abstract). How do you propose these protected 
> members be bridged should the proposal pass?
> From: Vanderlei Martinelli via swift-evolution 
> <mailto:swift-evolution@swift.org>
> Sent: ‎29/‎05/‎2016 06:56 PM
> To: swift-evolution <mailto:swift-evolution@swift.org>
> Subject: Re: [swift-evolution] [Proposal] Protected Access Level
> 
> Thank you all for your comments. :-)
> 
> Well... My goal is to keep the thing really simple and do not start a new 
> "OOP x POP" (or "something" x "other thing") war.
> 
> "Protected" access level is not a new concept at all (except for the Swift 
> language), so I did not propose anything preposterous.
> 
> Of course in the Swift of my dreams we also have "abstract" access level 
> modifier, "protected" access level, *real* "private" access level and "file" 
> access level modifier (along with many, many other things, of course). But 
> this proposal is not about this. It is only about include the "protected" 
> access level.
> 
> There is, however, something that I need to get off my chest: I really would 
> like to have the freedom to go to the depths with protocols as well with 
> classes. I work in real apps everyday that uses Cocoa frameworks (based on 
> classes) and these apps must be shipped and I like them well written. Maybe 
> am I insane for proposing a better support for classes in Swift? If so, this 
> explains why every time I suggest better support for classes in Swift there 
> is an endless discussion and someone proclaims the death of OOP and is it. 
> OK... Maybe someday we will not have more classes in Swift. Until there: the 
> current language status is the best way to handle OOP in Swift? Or is there a 
> better way? I think there is.
> 
> 
> Regards,
> 
> Vanderlei Martinelli
> 
> 
> 
> 
> 
> 
> 
> On Sat, May 28, 2016 at 7:52 PM, Vanderlei Martinelli 
> <vmartine...@ale

Re: [swift-evolution] [Proposal] Protected Access Level

[Callionica (Swift) via swift-evolution]

Here's demo code for emulating protected in Swift:
https://gist.github.com/callionica/19da0763c0b0b4c504fc5f46d07e8ee8
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[Callionica (Swift) via swift-evolution]

I can't reply directly to all the points in this thread, but I will just
say that there are ways of emulating protected in the language as it exists
today:

If the goal is to have functions that can be overridden by subclasses
without being called by external classes, you can create a parameter of a
public type with a private initializer and use it in all "protected" member
functions. No external code will be able to call such functions because
they cannot create an argument of the correct type.

If external classes need to both override and call the "protected" members,
you'll need to arrange to pass the key to derived classes which you can do
by taking a function as an argument to the base class initializer. The base
class then calls the function to pass the key to the derived class. This
way only parties that are able to control the function passed to the
initializer are able to obtain the key necessary to call the "protected"
member functions.

You can produce a lot of different access control mechanisms using the same
idea.

I'll write something up at http://www.callionica.com/developer in the next
day or so

-- Callionica

On Sun, May 29, 2016 at 2:55 PM, Vanderlei Martinelli via swift-evolution <
swift-evolution@swift.org> wrote:

> Thank you all for your comments. :-)
>
> Well... My goal is to keep the thing really simple and do not start a new
> "OOP x POP" (or "something" x "other thing") war.
>
> "Protected" access level is not a new concept at all (except for the Swift
> language), so I did not propose anything preposterous.
>
> Of course in the Swift of my dreams we also have "abstract" access level
> modifier, "protected" access level, *real* "private" access level and
> "file" access level modifier (along with many, many other things, of
> course). But this proposal is not about this. It is only about include the
> "protected" access level.
>
> There is, however, something that I need to get off my chest: I really
> would like to have the freedom to go to the depths with protocols as well
> with classes. I work in real apps everyday that uses Cocoa frameworks
> (based on classes) and these apps must be shipped and I like them well
> written. Maybe am I insane for proposing a better support for classes in
> Swift? If so, this explains why every time I suggest better support for
> classes in Swift there is an endless discussion and someone proclaims the
> death of OOP and is it. OK... Maybe someday we will not have more classes
> in Swift. Until there: the current language status is the best way to
> handle OOP in Swift? Or is there a better way? I think there is.
>
>
> Regards,
>
> Vanderlei Martinelli
>
>
>
>
>>
>>
>
> On Sat, May 28, 2016 at 7:52 PM, Vanderlei Martinelli <
> vmartine...@alecrim.com> wrote:
>
>> Hello.
>>
>>
>> This is the first draft. I'd like to know your opinion about it.
>>
>> (I know that this subject could have been discussed before. If so, please
>> indicate me the correct thread to follow and interact.)
>>
>>
>> Regards,
>>
>> Vanderlei Martinelli
>>
>>
>> ---
>>
>>
>> Introduction
>>
>> Protected access level will enable entities to be used within the
>> container type and by derived types only.
>> Motivation
>>
>> Today Swift has three access levels (public, internal and private), but
>> lacks a way to describe a member that can be only visible to its type or
>> derived types.
>>
>> A common case is the UIView from UIKit. Many developers are tempted to
>> make this call:
>>
>> view.layoutSubviews()
>>
>> The documentation says: "You should not call this method directly. If you
>> want to force a layout update, call the setNeedsLayoutmethod instead to
>> do so prior to the next drawing update. If you want to update the layout of
>> your views immediately, call the layoutIfNeeded method."
>>
>> But yes, you should call this method directly if you are subclassing the
>> view and needs to perform additional layout to its subviews ("subclasses
>> can override this method as needed"):
>>
>> public override func layoutSubviews() {
>> // We are calling the super method directly here.
>> super.layoutSubviews()
>>
>> // Do more adjustments to this view's subviews...}
>>
>> So, yes, we can call this method directly when subclassing, but the Swift
>> compiler will not prevent you from do this when not subclassing or from any
>> other foreign class. It will not even issue a warning.
>>
>> In Objective-C problems like this are usually "solved" my adding a kind
>> of "protected" header (.h) that is intended to be included only when the
>> developer is subclassing. In Swift we do not have headers, but we have the
>> new access level model. So, if the declaration of this method was...
>>
>> protected func layoutSubviews()
>>
>> ... no one outside the class or derived classes would be allowed to call
>> this method directly.
>>
>> Of course, there are other cases in the Cocoa frameworks and there are
>> many other cases when we are developing software in Swift that the

Re: [swift-evolution] [Proposal] Protected Access Level

[Vanderlei Martinelli via swift-evolution]

Thank you all for your comments. :-)

Well... My goal is to keep the thing really simple and do not start a new
"OOP x POP" (or "something" x "other thing") war.

"Protected" access level is not a new concept at all (except for the Swift
language), so I did not propose anything preposterous.

Of course in the Swift of my dreams we also have "abstract" access level
modifier, "protected" access level, *real* "private" access level and
"file" access level modifier (along with many, many other things, of
course). But this proposal is not about this. It is only about include the
"protected" access level.

There is, however, something that I need to get off my chest: I really
would like to have the freedom to go to the depths with protocols as well
with classes. I work in real apps everyday that uses Cocoa frameworks
(based on classes) and these apps must be shipped and I like them well
written. Maybe am I insane for proposing a better support for classes in
Swift? If so, this explains why every time I suggest better support for
classes in Swift there is an endless discussion and someone proclaims the
death of OOP and is it. OK... Maybe someday we will not have more classes
in Swift. Until there: the current language status is the best way to
handle OOP in Swift? Or is there a better way? I think there is.


Regards,

Vanderlei Martinelli




>
>

On Sat, May 28, 2016 at 7:52 PM, Vanderlei Martinelli <
vmartine...@alecrim.com> wrote:

> Hello.
>
>
> This is the first draft. I'd like to know your opinion about it.
>
> (I know that this subject could have been discussed before. If so, please
> indicate me the correct thread to follow and interact.)
>
>
> Regards,
>
> Vanderlei Martinelli
>
>
> ---
>
>
> Introduction
>
> Protected access level will enable entities to be used within the
> container type and by derived types only.
> Motivation
>
> Today Swift has three access levels (public, internal and private), but
> lacks a way to describe a member that can be only visible to its type or
> derived types.
>
> A common case is the UIView from UIKit. Many developers are tempted to
> make this call:
>
> view.layoutSubviews()
>
> The documentation says: "You should not call this method directly. If you
> want to force a layout update, call the setNeedsLayoutmethod instead to
> do so prior to the next drawing update. If you want to update the layout of
> your views immediately, call the layoutIfNeeded method."
>
> But yes, you should call this method directly if you are subclassing the
> view and needs to perform additional layout to its subviews ("subclasses
> can override this method as needed"):
>
> public override func layoutSubviews() {
> // We are calling the super method directly here.
> super.layoutSubviews()
>
> // Do more adjustments to this view's subviews...}
>
> So, yes, we can call this method directly when subclassing, but the Swift
> compiler will not prevent you from do this when not subclassing or from any
> other foreign class. It will not even issue a warning.
>
> In Objective-C problems like this are usually "solved" my adding a kind of
> "protected" header (.h) that is intended to be included only when the
> developer is subclassing. In Swift we do not have headers, but we have the
> new access level model. So, if the declaration of this method was...
>
> protected func layoutSubviews()
>
> ... no one outside the class or derived classes would be allowed to call
> this method directly.
>
> Of course, there are other cases in the Cocoa frameworks and there are
> many other cases when we are developing software in Swift that the
> protected access level would be very usefull.
> Proposed solution
>
> Create the protected access level.
> Detailed designReference Types (classes)
>
> When declarated by a class the protected member will be visible to the
> class itself and all the derived classes.
>
> // BaseClass.swiftpublic class BaseClass {
> public protected(set) var x = 20
> protected let y = 10
>
> protected func doSomething() {
> // ...
> }}
> // DerivedClass.swiftpublic class DerivedClass: BaseClass {
> protected override doSomething() {
> self.x = 10 * self.y
> }}
>
> If the member is declared as final then it will be visible but not can be
> overrided by the derived classes. Just like it works with other access
> levels.
> Value Types (structs, enums, etc.)
>
> Value types cannot have derived types. In this case the protected access
> level does not make sense and will not be allowed in their members.
> Protocols
>
> Protocols do not declare access level for their members. So the protected 
> access
> level is not applicable here.
> Extensions
>
> Extensions will not be able do be protected nor their members.
> Special Note
>
> The protected access level can only be applied to classes, structs and
> other types when nested inside other type. So the following code will not
> compile:
>
> // ERROR: A first level class cannot be protected.
> 

Re: [swift-evolution] [Proposal] Protected Access Level

[Tino Heth via swift-evolution]

I'm not opposed to the idea of finer-grained access levels in general, but if 
the current system is extended, the change imho should be more "holistic":
Right now, class hierarchy has no effect on accessibility, and it feels odd to 
have access level that is different from the others.
Doing so would rise questions like "why it is not possible to have a method 
that can be called from the current module, and from subclasses?".

There are several scenarios that can't be modeled in Swift now, and that still 
couldn't be modeled with a new "protected"-level (especially methods that can't 
be called from outside, but can be overridden by subclasses could be very 
useful).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[L Mihalkovic via swift-evolution]

The rust compiler is written in rust… many compilers are bootstrapped and then 
written in their own language. Looking at the swift language vs C++ features 
used in the current compiler, I wager it would be a suicide mission to try with 
Swift 3.0.

> On May 29, 2016, at 2:27 PM, Leonardo Pessoa  wrote:
> 
> 
>> attempting to write a Swift compiler in Swift today would probably result in 
>> hard to read/reason about source code. 
> 
> Hmm, I still have to find some time to start working in this...

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[Goffredo Marocchi via swift-evolution]

Multiple ways for multiple needs. The same way you can support both delegation 
as well as blocks based callbacks.

Sent from my iPhone

> On 29 May 2016, at 13:23, Leonardo Pessoa via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> You know the default access is was is used for this, right? And in this case 
> I don't think they meant it for external subclasses to be able to access this 
> change.
> 
> I think this is how Swift was meant to work allowing only classes in a 
> certain module to access such "private shared" parts and using delegates for 
> these extensions. I'm not saying I'm against protecteds but it's hard to get 
> used to use another way of programming when most other languages we 
> previously learned had a different philosophy.
> 
> Sure everyone has the right to discuss they like this new philosophy or not 
> but we should also question ourselves if this is the right way to go because 
> it will completely change the philosophy of the language. Should this pass, 
> we may start facing the core library using the delegate philosophy (I don't 
> believe Apple will change it) and third-party modern frameworks using old 
> school subclassing with protected parts. That's two ways of doing the same 
> thing and I don't think this will be much good to anyone.
> From: Charlie Monroe via swift-evolution
> Sent: ‎29/‎05/‎2016 08:29 AM
> To: Brent Royal-Gordon
> Cc: swift-evolution
> Subject: Re: [swift-evolution] [Proposal] Protected Access Level
> 
> 
> > My answer is this: There is nothing magical about being a subclass that 
> > ought to grant access to those methods.
> 
> There is - it's a family member that you let use your summer house. Without 
> the metaphor, here is an example for this being useful: 
> 
> URLConnection subclass may want to update the URL in case of a redirect, but 
> you don't really want to expose the setter for the URL to public.
> 
> > For instance, if your subclass grows very complicated and you extract a 
> > helper object, it's perfectly reasonable for that helper object to want to 
> > access the "subclass-only" API.
> 
> That's what "friend" classes are for in C++, similar concept would be applied 
> here.
> 
> > Contrarily, simple subclasses might not need that API, and exposing it to 
> > them would be an unnecessary risk. And there are things which you don't 
> > subclass at all which could benefit from being hidden away—think of the 
> > Objective-C runtime, which has some parts which every app needs (like the 
> > definition of `BOOL`) and othe
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[Leonardo Pessoa via swift-evolution]

> attempting to write a Swift compiler in Swift today would probably result in 
> hard to read/reason about source code. 

Hmm, I still have to find some time to start working in this...
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[Leonardo Pessoa via swift-evolution]

You know the default access is was is used for this, right? And in this case I 
don't think they meant it for external subclasses to be able to access this 
change.

I think this is how Swift was meant to work allowing only classes in a certain 
module to access such "private shared" parts and using delegates for these 
extensions. I'm not saying I'm against protecteds but it's hard to get used to 
use another way of programming when most other languages we previously learned 
had a different philosophy.

Sure everyone has the right to discuss they like this new philosophy or not but 
we should also question ourselves if this is the right way to go because it 
will completely change the philosophy of the language. Should this pass, we may 
start facing the core library using the delegate philosophy (I don't believe 
Apple will change it) and third-party modern frameworks using old school 
subclassing with protected parts. That's two ways of doing the same thing and I 
don't think this will be much good to anyone.


-Original Message-
From: "Charlie Monroe via swift-evolution" <swift-evolution@swift.org>
Sent: ‎29/‎05/‎2016 08:29 AM
To: "Brent Royal-Gordon" <br...@architechies.com>
Cc: "swift-evolution" <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Proposal] Protected Access Level


> My answer is this: There is nothing magical about being a subclass that ought 
> to grant access to those methods.

There is - it's a family member that you let use your summer house. Without the 
metaphor, here is an example for this being useful: 

URLConnection subclass may want to update the URL in case of a redirect, but 
you don't really want to expose the setter for the URL to public.

> For instance, if your subclass grows very complicated and you extract a 
> helper object, it's perfectly reasonable for that helper object to want to 
> access the "subclass-only" API.

That's what "friend" classes are for in C++, similar concept would be applied 
here.

> Contrarily, simple subclasses might not need that API, and exposing it to 
> them would be an unnecessary risk. And there are things which you don't 
> subclass at all which could benefit from being hidden away—think of the 
> Objective-C runtime, which has some parts which every app needs (like the 
> definition of `BOOL`) and othe

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[L Mihalkovic via swift-evolution]

> On May 29, 2016, at 9:38 AM, Charlie Monroe via swift-evolution 
>  wrote:
> 
> Ditto - I would love to be able to disallow non-subclasses 
> accessing/modifying some variables.
> 
> Though, I'm not sure what would be the stand on this from the core team - 
> according to Apple's blog they've already considered protected access level:
> 
> https://developer.apple.com/swift/blog/?id=11
> 
> Charlie
> 

let’s perpetuate the helplessness because developers will not understand. That 
might be the rationale that also prevailed to make swift have no namespaces: 
Objective-c did not… funny thing is, the compiler source code would be 
miserable to read if its source code was organized in terms of classes and 
modules (lib). Which means that aside from accessibility to LLVM API, 
attempting to write a Swift compiler in Swift today would probably result in 
hard to read/reason about source code. 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 29 May 2016, at 11:30, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> There is nothing magical about being a subclass that ought to grant access to 
> those methods

Hello Brent,

You must admit that when thinking about the words inheritance and parent/child 
classes the mind wanders to suggest the contrary actually. I know it is a 
personal loaded opinion, but I think having private headers to expose 
properties, variables, and methods to subclasses as leading to poor looking 
code generally (one must also keep in mind teams composed of less than pure 
elite coders) and in itself I have never liked the concept. 

Subclassing with abstract methods and protected access always felt natural and 
I think we should give that power to those who use Swift rather than tie OOP's 
arms a bit behind its back. It would be wrong if this were to happen in order 
to push people down to functional or POP approaches just because subclassing 
can be abused. 
I have always felt that we should give better options rather than restricting 
what we feel it may be abused (yet useful if used correctly).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[Charlie Monroe via swift-evolution]

> My answer is this: There is nothing magical about being a subclass that ought 
> to grant access to those methods.

There is - it's a family member that you let use your summer house. Without the 
metaphor, here is an example for this being useful: 

URLConnection subclass may want to update the URL in case of a redirect, but 
you don't really want to expose the setter for the URL to public.

> For instance, if your subclass grows very complicated and you extract a 
> helper object, it's perfectly reasonable for that helper object to want to 
> access the "subclass-only" API.

That's what "friend" classes are for in C++, similar concept would be applied 
here.

> Contrarily, simple subclasses might not need that API, and exposing it to 
> them would be an unnecessary risk. And there are things which you don't 
> subclass at all which could benefit from being hidden away—think of the 
> Objective-C runtime, which has some parts which every app needs (like the 
> definition of `BOOL`) and othe

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[Brent Royal-Gordon via swift-evolution]

> Unless I'm missing something Brent, your suggestions still wouldn't allow the 
> developer to provide a public class in a module designed to be subclassed by 
> clients in another module and access these "private" details, which is a real 
> problem I'm having in my current project.
> 
> I have a framework which provides an abstract model object designed to be 
> subclassed (and yes it has to be a class and not a struct for a multitude of 
> reasons ) by clients of the framework. There are several convenience methods 
> + properties I have exposed for subclasses to use, but they should really be 
> implementation details; a client using these model objects should not have to 
> know about them. Even worse, several of the properties are mutable so the 
> subclasses can modify them, but they certainly should *not* be modified by 
> anything else.
> 
> Right now, I'm limited to simply commenting something akin to "DO NOT CALL" 
> next to these methods/properties, which definitely goes against Swift's 
> safety focus. For these reasons, I'm 100% in support of a protected access 
> control modifier.

That's a little bit of a different use case than the `layoutSubviews()` case 
discussed in the proposal.

My answer is this: There is nothing magical about being a subclass that ought 
to grant access to those methods. For instance, if your subclass grows very 
complicated and you extract a helper object, it's perfectly reasonable for that 
helper object to want to access the "subclass-only" API. Contrarily, simple 
subclasses might not need that API, and exposing it to them would be an 
unnecessary risk. And there are things which you don't subclass at all which 
could benefit from being hidden away—think of the Objective-C runtime, which 
has some parts which every app needs (like the definition of `BOOL`) and other 
parts which are extraordinarily dangerous and should only be available to code 
which needs it (like `method_exchangeImplementations`).

The Objective-C solution—using a separate header file—actually acknowledges 
this fact. Even though the header is called "UIGestureRecognizerSubclass.h", it 
is not really limited to subclasses; any code can import and use that API. It's 
just sectioned off *by default*, like keeping all the kitchen knives in a 
sharps drawer. And the Objective-C runtime, which doesn't contain (many) 
classes, can use this approach too:  is implicitly available, 
while  is something you have to ask for explicitly.

There are a few ways you could bring this same "sharps drawer" approach to 
Swift. For instance—without adding any language features—you could create an 
ancillary struct which merely serves to segregate all the dangerous APIs:

public class UIGestureRecognizer {
public private(set) var state: UIGestureRecognizerState {...}

private func ignoreTouch(touch: UITouch, forEvent event: 
UIEvent) {...}
private func reset() {...}

// etc. for the other APIs

/// Contains methods and properties which directly affect the 
state of the gesture recognizer.
///
/// -Warning: Only use the state engine when implementing a 
custom gesture recognizer yourself.
/// The state engine is delicate and modifying 
behind a gesture recognizer's back is likely to 
/// break it.
public var stateEngine: StateEngine { return 
StateEngine(gestureRecognizer: self) }

public struct StateEngine {
private var gestureRecognizer: UIGestureRecognizer

public var state: UIGestureRecognizerState {
get { return gestureRecognizer.state }
nonmutating set { gestureRecognizer.state = 
newValue }
}

public func ignoreTouch(touch: UITouch, forEvent event: 
UIEvent) {
gestureRecognizer.ignoreTouch(touch, forEvent: 
event)
}

public func reset() {
gestureRecognizer.reset()
}

/// etc. for the other APIs
}
}

Now ordinary clients of UIGestureRecognizer won't see a bunch of random methods 
strewn around with doc comments warning not to use them; they'll see *one* 
property with an intimidating name and a scary comment. You could even give the 
property a name like `internals` to make it clearer that you shouldn't be 
touching this unless you know what you're doing. On the other hand, any code 
that needs to *can* access these features, whether or not that code happens to 
be located in a subclass of the class in question.

Obviously, this approach 

Re: [swift-evolution] [Proposal] Protected Access Level

[Charlie Monroe via swift-evolution]

I agree - both will need to be addressed in the future to make the language 
complete. There are some valid points, however, in the blog post - would you 
allow extensions to access protected variables and potentially expose them to 
other classes? I.e:

/// Class in module A:
class View {
protected func layoutSubviews()
}

/// In module B:
extension View {
func doLayoutSubviews() {
self.layoutSubviews()
}
}

Or would you disallow access from extensions to prevent this kind of abuse?

> On May 29, 2016, at 11:19 AM, Goffredo Marocchi  wrote:
> 
> Without wither abstract classes or a protected access modifier, the status 
> quo, that kind of ExceptionThisMethodShouldBeOverridden are really ugly bad 
> code there is no alternative to beyond a religious stop using classes and sub 
> classing... did you not know about your pop saviour ;)? 
> 
> Sent from my iPhone
> 
>> On 29 May 2016, at 08:38, Charlie Monroe via swift-evolution 
>>  wrote:
>> 
>> Ditto - I would love to be able to disallow non-subclasses 
>> accessing/modifying some variables.
>> 
>> Though, I'm not sure what would be the stand on this from the core team - 
>> according to Apple's blog they've already considered protected access level:
>> 
>> https://developer.apple.com/swift/blog/?id=11
>> 
>> Charlie
>> 
>> 
>>> On May 29, 2016, at 7:56 AM, Riley Testut via swift-evolution 
>>>  wrote:
>>> 
>>> Unless I'm missing something Brent, your suggestions still wouldn't allow 
>>> the developer to provide a public class in a module designed to be 
>>> subclassed by clients in another module and access these "private" details, 
>>> which is a real problem I'm having in my current project.
>>> 
>>> I have a framework which provides an abstract model object designed to be 
>>> subclassed (and yes it has to be a class and not a struct for a multitude 
>>> of reasons ) by clients of the framework. There are several convenience 
>>> methods + properties I have exposed for subclasses to use, but they should 
>>> really be implementation details; a client using these model objects should 
>>> not have to know about them. Even worse, several of the properties are 
>>> mutable so the subclasses can modify them, but they certainly should *not* 
>>> be modified by anything else.
>>> 
>>> Right now, I'm limited to simply commenting something akin to "DO NOT CALL" 
>>> next to these methods/properties, which definitely goes against Swift's 
>>> safety focus. For these reasons, I'm 100% in support of a protected access 
>>> control modifier.
>>> 
 On May 28, 2016, at 8:11 PM, Brent Royal-Gordon via swift-evolution 
  wrote:
 
 To begin with, I'm not a fan of `protected` access. But even leaving that 
 aside, I have a few questions and critiques.
 
> A common case is the UIView from UIKit. Many developers are tempted to 
> make this call:
> 
> view.layoutSubviews()
> The documentation says: "You should not call this method directly. If you 
> want to force a layout update, call the setNeedsLayoutmethod instead to 
> do so prior to the next drawing update. If you want to update the layout 
> of your views immediately, call the layoutIfNeeded method."
 
 This example is illuminating in several ways.
 
 * The rule is not simply that "only the class should call 
 `layoutSubviews()`"; it is effectively "*you* should never call 
 `layoutSubviews()` except when `super`ing up from your override". Calling 
 `layoutSubviews()` from `insertRows(at:)` is just as much a mistake if 
 `insertRows(at:)` is part of the class as if it is not. So isn't 
 `protected` insufficiently strict to properly serve this use case?
 
 * At the same time, something outside `layoutSubviews()` has to be able to 
 call `layoutSubviews()`. In the case of UIKit, though, that "something" is 
 always within UIKit itself, never outside it. So should `protected` have a 
 "bottom", a level below which calls are unrestricted? For instance, in 
 UIKit's case you might have `protected fileprivate`, meaning "anything up 
 to `fileprivate` has unrestricted use; anything above that can override 
 and `super` up from its override, but not use it any other way".
 
 protected fileprivate func layoutSubviews()
 
 * `layoutSubviews()` is also something you should probably always `super` 
 up to. Have you considered addressing `super` requirements at all?
 
 In short, is a traditional `protected` really the feature you want to 
 handle this use case, or would a very different design actually suit it a 
 lot better?
 
> When declarated by a class the protected member will be visible to the 
> class itself and all the derived classes.
 
 In what scope? The same as the class?
 
 Is there not room 

Re: [swift-evolution] [Proposal] Protected Access Level

[Charlie Monroe via swift-evolution]

Ditto - I would love to be able to disallow non-subclasses accessing/modifying 
some variables.

Though, I'm not sure what would be the stand on this from the core team - 
according to Apple's blog they've already considered protected access level:

https://developer.apple.com/swift/blog/?id=11

Charlie


> On May 29, 2016, at 7:56 AM, Riley Testut via swift-evolution 
>  wrote:
> 
> Unless I'm missing something Brent, your suggestions still wouldn't allow the 
> developer to provide a public class in a module designed to be subclassed by 
> clients in another module and access these "private" details, which is a real 
> problem I'm having in my current project.
> 
> I have a framework which provides an abstract model object designed to be 
> subclassed (and yes it has to be a class and not a struct for a multitude of 
> reasons ) by clients of the framework. There are several convenience methods 
> + properties I have exposed for subclasses to use, but they should really be 
> implementation details; a client using these model objects should not have to 
> know about them. Even worse, several of the properties are mutable so the 
> subclasses can modify them, but they certainly should *not* be modified by 
> anything else.
> 
> Right now, I'm limited to simply commenting something akin to "DO NOT CALL" 
> next to these methods/properties, which definitely goes against Swift's 
> safety focus. For these reasons, I'm 100% in support of a protected access 
> control modifier.
> 
>> On May 28, 2016, at 8:11 PM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>> To begin with, I'm not a fan of `protected` access. But even leaving that 
>> aside, I have a few questions and critiques.
>> 
>>> A common case is the UIView from UIKit. Many developers are tempted to make 
>>> this call:
>>> 
>>> view.layoutSubviews()
>>> The documentation says: "You should not call this method directly. If you 
>>> want to force a layout update, call the setNeedsLayoutmethod instead to do 
>>> so prior to the next drawing update. If you want to update the layout of 
>>> your views immediately, call the layoutIfNeeded method."
>> 
>> This example is illuminating in several ways.
>> 
>> * The rule is not simply that "only the class should call 
>> `layoutSubviews()`"; it is effectively "*you* should never call 
>> `layoutSubviews()` except when `super`ing up from your override". Calling 
>> `layoutSubviews()` from `insertRows(at:)` is just as much a mistake if 
>> `insertRows(at:)` is part of the class as if it is not. So isn't `protected` 
>> insufficiently strict to properly serve this use case?
>> 
>> * At the same time, something outside `layoutSubviews()` has to be able to 
>> call `layoutSubviews()`. In the case of UIKit, though, that "something" is 
>> always within UIKit itself, never outside it. So should `protected` have a 
>> "bottom", a level below which calls are unrestricted? For instance, in 
>> UIKit's case you might have `protected fileprivate`, meaning "anything up to 
>> `fileprivate` has unrestricted use; anything above that can override and 
>> `super` up from its override, but not use it any other way".
>> 
>>   protected fileprivate func layoutSubviews()
>> 
>> * `layoutSubviews()` is also something you should probably always `super` up 
>> to. Have you considered addressing `super` requirements at all?
>> 
>> In short, is a traditional `protected` really the feature you want to handle 
>> this use case, or would a very different design actually suit it a lot 
>> better?
>> 
>>> When declarated by a class the protected member will be visible to the 
>>> class itself and all the derived classes.
>> 
>> In what scope? The same as the class?
>> 
>> Is there not room for, for instance, "usable without restriction in this 
>> file, override-only in the rest of this module, invisible outside it"? For 
>> instance, `internal(protected) fileprivate`, or perhaps `internal(override) 
>> fileprivate`? `layoutSubviews()` might then be `public(override) 
>> fileprivate`—the ability to override is public, the ability to use it 
>> unrestricted is filewide.
>> 
>>   public(override) fileprivate func layoutSubviews()
>>   internal(override) fileprivate func privateSubclassingHook()
>> 
>>> public protected(set) var x = 20
>> 
>> Of course, that might be difficult to combine with the `(set)` syntax. 
>> `public(set: override)`, maybe? With, for instance, `public internal(set: 
>> override) private(set)` if you want the property's getter public and its 
>> setter overridable internally and callable in private scope.
>> 
>>   public(override) fileprivate func layoutSubviews()
>>   internal(override) fileprivate func privateSubclassingHook()
>>   public(get, set: override) internal(set) var x = 20
>> 
>> But there's something about this that's starting to seem a little rotten. I 
>> think the problem is that we're not really trying to widen the ability to 
>> override, 

Re: [swift-evolution] [Proposal] Protected Access Level

[Riley Testut via swift-evolution]

Unless I'm missing something Brent, your suggestions still wouldn't allow the 
developer to provide a public class in a module designed to be subclassed by 
clients in another module and access these "private" details, which is a real 
problem I'm having in my current project.

I have a framework which provides an abstract model object designed to be 
subclassed (and yes it has to be a class and not a struct for a multitude of 
reasons ) by clients of the framework. There are several convenience methods + 
properties I have exposed for subclasses to use, but they should really be 
implementation details; a client using these model objects should not have to 
know about them. Even worse, several of the properties are mutable so the 
subclasses can modify them, but they certainly should *not* be modified by 
anything else.

Right now, I'm limited to simply commenting something akin to "DO NOT CALL" 
next to these methods/properties, which definitely goes against Swift's safety 
focus. For these reasons, I'm 100% in support of a protected access control 
modifier.

> On May 28, 2016, at 8:11 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> To begin with, I'm not a fan of `protected` access. But even leaving that 
> aside, I have a few questions and critiques.
> 
>> A common case is the UIView from UIKit. Many developers are tempted to make 
>> this call:
>> 
>> view.layoutSubviews()
>> The documentation says: "You should not call this method directly. If you 
>> want to force a layout update, call the setNeedsLayoutmethod instead to do 
>> so prior to the next drawing update. If you want to update the layout of 
>> your views immediately, call the layoutIfNeeded method."
> 
> This example is illuminating in several ways.
> 
> * The rule is not simply that "only the class should call 
> `layoutSubviews()`"; it is effectively "*you* should never call 
> `layoutSubviews()` except when `super`ing up from your override". Calling 
> `layoutSubviews()` from `insertRows(at:)` is just as much a mistake if 
> `insertRows(at:)` is part of the class as if it is not. So isn't `protected` 
> insufficiently strict to properly serve this use case?
> 
> * At the same time, something outside `layoutSubviews()` has to be able to 
> call `layoutSubviews()`. In the case of UIKit, though, that "something" is 
> always within UIKit itself, never outside it. So should `protected` have a 
> "bottom", a level below which calls are unrestricted? For instance, in 
> UIKit's case you might have `protected fileprivate`, meaning "anything up to 
> `fileprivate` has unrestricted use; anything above that can override and 
> `super` up from its override, but not use it any other way".
> 
>protected fileprivate func layoutSubviews()
> 
> * `layoutSubviews()` is also something you should probably always `super` up 
> to. Have you considered addressing `super` requirements at all?
> 
> In short, is a traditional `protected` really the feature you want to handle 
> this use case, or would a very different design actually suit it a lot better?
> 
>> When declarated by a class the protected member will be visible to the class 
>> itself and all the derived classes.
> 
> In what scope? The same as the class?
> 
> Is there not room for, for instance, "usable without restriction in this 
> file, override-only in the rest of this module, invisible outside it"? For 
> instance, `internal(protected) fileprivate`, or perhaps `internal(override) 
> fileprivate`? `layoutSubviews()` might then be `public(override) 
> fileprivate`—the ability to override is public, the ability to use it 
> unrestricted is filewide.
> 
>public(override) fileprivate func layoutSubviews()
>internal(override) fileprivate func privateSubclassingHook()
> 
>> public protected(set) var x = 20
> 
> Of course, that might be difficult to combine with the `(set)` syntax. 
> `public(set: override)`, maybe? With, for instance, `public internal(set: 
> override) private(set)` if you want the property's getter public and its 
> setter overridable internally and callable in private scope.
> 
>public(override) fileprivate func layoutSubviews()
>internal(override) fileprivate func privateSubclassingHook()
>public(get, set: override) internal(set) var x = 20
> 
> But there's something about this that's starting to seem a little rotten. I 
> think the problem is that we're not really trying to widen the ability to 
> override, we're trying to restrict the ability to call. Let's try 
> restructuring along those lines:
> 
>public fileprivate(call) func layoutSubviews()
>internal fileprivate(call) func privateSubclassingHook()
>public internal(set: call) var x = 20
> 
> That seems much cleaner to me.
> 
>> If the member is declared as final then it will be visible but not can be 
>> overrided by the derived classes. Just like it works with other access 
>> levels.
> 
> With the "overridable but otherwise unusable" conception 

Re: [swift-evolution] [Proposal] Protected Access Level

[Brent Royal-Gordon via swift-evolution]

To begin with, I'm not a fan of `protected` access. But even leaving that 
aside, I have a few questions and critiques.

> A common case is the UIView from UIKit. Many developers are tempted to make 
> this call:
> 
> view.layoutSubviews()
> The documentation says: "You should not call this method directly. If you 
> want to force a layout update, call the setNeedsLayoutmethod instead to do so 
> prior to the next drawing update. If you want to update the layout of your 
> views immediately, call the layoutIfNeeded method."

This example is illuminating in several ways.

* The rule is not simply that "only the class should call `layoutSubviews()`"; 
it is effectively "*you* should never call `layoutSubviews()` except when 
`super`ing up from your override". Calling `layoutSubviews()` from 
`insertRows(at:)` is just as much a mistake if `insertRows(at:)` is part of the 
class as if it is not. So isn't `protected` insufficiently strict to properly 
serve this use case?

* At the same time, something outside `layoutSubviews()` has to be able to call 
`layoutSubviews()`. In the case of UIKit, though, that "something" is always 
within UIKit itself, never outside it. So should `protected` have a "bottom", a 
level below which calls are unrestricted? For instance, in UIKit's case you 
might have `protected fileprivate`, meaning "anything up to `fileprivate` has 
unrestricted use; anything above that can override and `super` up from its 
override, but not use it any other way".

protected fileprivate func layoutSubviews()

* `layoutSubviews()` is also something you should probably always `super` up 
to. Have you considered addressing `super` requirements at all?

In short, is a traditional `protected` really the feature you want to handle 
this use case, or would a very different design actually suit it a lot better?

> When declarated by a class the protected member will be visible to the class 
> itself and all the derived classes.

In what scope? The same as the class?

Is there not room for, for instance, "usable without restriction in this file, 
override-only in the rest of this module, invisible outside it"? For instance, 
`internal(protected) fileprivate`, or perhaps `internal(override) fileprivate`? 
`layoutSubviews()` might then be `public(override) fileprivate`—the ability to 
override is public, the ability to use it unrestricted is filewide.

public(override) fileprivate func layoutSubviews()
internal(override) fileprivate func privateSubclassingHook()

> public protected(set) var x = 20

Of course, that might be difficult to combine with the `(set)` syntax. 
`public(set: override)`, maybe? With, for instance, `public internal(set: 
override) private(set)` if you want the property's getter public and its setter 
overridable internally and callable in private scope.

public(override) fileprivate func layoutSubviews()
internal(override) fileprivate func privateSubclassingHook()
public(get, set: override) internal(set) var x = 20

But there's something about this that's starting to seem a little rotten. I 
think the problem is that we're not really trying to widen the ability to 
override, we're trying to restrict the ability to call. Let's try restructuring 
along those lines:

public fileprivate(call) func layoutSubviews()
internal fileprivate(call) func privateSubclassingHook()
public internal(set: call) var x = 20

That seems much cleaner to me.

> If the member is declared as final then it will be visible but not can be 
> overrided by the derived classes. Just like it works with other access levels.

With the "overridable but otherwise unusable" conception I'm suggesting, this 
would not be the case, of course.

> Protocols
> 
> Protocols do not declare access level for their members. So the protected 
> access level is not applicable here.

But `protected` is quite different from other access levels; it does not limit 
the visibility of the symbols, but rather their use. And protocols face the 
same sort of problem as classes, where certain members are essentially override 
hooks and shouldn't be called directly outside a particular scope.

So I think we ought to allow `accesslevel(call)`, but not a plain `accesslevel`:

public fileprivate(call) func layoutSubviews()
internal fileprivate(call) func privateSubclassingHook()
public internal(set: call) var x = 20
internal(call) func protocolConformanceHook()
fileprivate(set: call) var onlyProtocolSetsThis: Int { get set }

> Extensions
> 
> Extensions will not be able do be protected nor their members.

This is very vague. There are several things extensions might try to do with 
protected members:

* Declare new ones
* Override existing ones
* Call existing ones

Which of these, if any, are permitted? Why?

In my conception, I would permit extensions to behave as the type they extended 
did. Extensions could declare new members with 

Re: [swift-evolution] [Proposal] Protected Access Level

[Leonardo Pessoa via swift-evolution]

If we're to introduce the protected visibility, I think we should as well make 
it automatically internal or introduce an explicit protected internal 
visibility. I've been through many cases while programming in C# 'where' this 
was handy (thou I cannot name one from memory right now; it's been so many 
years ago...)



-Original Message-
From: "Xiaodi Wu via swift-evolution" <swift-evolution@swift.org>
Sent: ‎28/‎05/‎2016 08:10 PM
To: "Vanderlei Martinelli" <vmartine...@alecrim.com>; "swift-evolution" 
<swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Proposal] Protected Access Level

Seems entirely reasonable to me. POP aficionados may object, but I think the 
pros and cons of this type of access are well trodden terrain and I think it's 
a net win to have this available in Swift going forward.

On Sat, May 28, 2016 at 18:53 Vanderlei Martinelli via swift-evolution 
<swift-evolution@swift.org> wrote:

Hello.




This is the first draft. I'd like to know your opinion about it.


(I know that this subject could have been discussed before. If so, please 
indicate me the correct thread to follow and interact.)




Regards,


Vanderlei Martinelli




---




Introduction
Protected access level will enable entities to be used within the container 
type and by derived types only.
Motivation
Today Swift has three access levels (public, internal and private), but lacks a 
way to describe a member that can be only visible to its type or derived types.
A common case is the UIView from UIKit. Many developers are tempted to make 
this call:
view.layoutSubviews()The documentation says: "You should not call this method 
directly. If you want to force a layout update, call the setNeedsLayoutmethod 
instead to do so prior to the next drawing update. If you want to update the 
layout of your views immediately, call the layoutIfNeeded method."
But yes, you should call this method directly if you are subclassing the view 
and needs to perform additional layout to its subviews ("subclasses can 
override this method as needed"):
public override func layoutSubviews() {
// We are calling the super method directly here.
super.layoutSubviews()

// Do more adjustments to this view's subviews...
}So, yes, we can call this method directly when subclassing, but the Swift 
compiler will not prevent you from do this when not subclassing or from any 
other foreign class. It will not even issue a warning.
In Objective-C problems like this are usually "solved" my adding a kind of 
"protected" header (.h) that is intended to be included only when the developer 
is subclassing. In Swift we do not have headers, but we have the new access 
level model. So, if the declaration of this method was...
protected func layoutSubviews()... no one outside the class or derived classes 
would be allowed to call this method directly.
Of course, there are other cases in the Cocoa frameworks and there are many 
other cases when we are developing software in Swift that the protected access 
level would be very usefull.
Proposed solution
Create the protected access level.
Detailed design
Reference Types (classes)
When declarated by a class the protected member will be visible to the class 
itself and all the derived classes.
// BaseClass.swift
public class BaseClass {
public protected(set) var x = 20
protected let y = 10

protected func doSomething() {
// ...
}
}

// DerivedClass.swift
public class DerivedClass: BaseClass {
protected override doSomething() {
self.x = 10 * self.y
}
}If the member is declared as final then it will be visible but not can be 
overrided by the derived classes. Just like it works with other access levels.
Value Types (structs, enums, etc.)
Value types cannot have derived types. In this case the protected access level 
does not make sense and will not be allowed in their members.
Protocols
Protocols do not declare access level for their members. So the protected 
access level is not applicable here.
Extensions
Extensions will not be able do be protected nor their members.
Special Note
The protected access level can only be applied to classes, structs and other 
types when nested inside other type. So the following code will not compile:
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

[Xiaodi Wu via swift-evolution]

Seems entirely reasonable to me. POP aficionados may object, but I think
the pros and cons of this type of access are well trodden terrain and I
think it's a net win to have this available in Swift going forward.
On Sat, May 28, 2016 at 18:53 Vanderlei Martinelli via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello.
>
>
> This is the first draft. I'd like to know your opinion about it.
>
> (I know that this subject could have been discussed before. If so, please
> indicate me the correct thread to follow and interact.)
>
>
> Regards,
>
> Vanderlei Martinelli
>
>
> ---
>
>
> Introduction
>
> Protected access level will enable entities to be used within the
> container type and by derived types only.
> Motivation
>
> Today Swift has three access levels (public, internal and private), but
> lacks a way to describe a member that can be only visible to its type or
> derived types.
>
> A common case is the UIView from UIKit. Many developers are tempted to
> make this call:
>
> view.layoutSubviews()
>
> The documentation says: "You should not call this method directly. If you
> want to force a layout update, call the setNeedsLayoutmethod instead to
> do so prior to the next drawing update. If you want to update the layout of
> your views immediately, call the layoutIfNeeded method."
>
> But yes, you should call this method directly if you are subclassing the
> view and needs to perform additional layout to its subviews ("subclasses
> can override this method as needed"):
>
> public override func layoutSubviews() {
> // We are calling the super method directly here.
> super.layoutSubviews()
>
> // Do more adjustments to this view's subviews...}
>
> So, yes, we can call this method directly when subclassing, but the Swift
> compiler will not prevent you from do this when not subclassing or from any
> other foreign class. It will not even issue a warning.
>
> In Objective-C problems like this are usually "solved" my adding a kind of
> "protected" header (.h) that is intended to be included only when the
> developer is subclassing. In Swift we do not have headers, but we have the
> new access level model. So, if the declaration of this method was...
>
> protected func layoutSubviews()
>
> ... no one outside the class or derived classes would be allowed to call
> this method directly.
>
> Of course, there are other cases in the Cocoa frameworks and there are
> many other cases when we are developing software in Swift that the
> protected access level would be very usefull.
> Proposed solution
>
> Create the protected access level.
> Detailed designReference Types (classes)
>
> When declarated by a class the protected member will be visible to the
> class itself and all the derived classes.
>
> // BaseClass.swiftpublic class BaseClass {
> public protected(set) var x = 20
> protected let y = 10
>
> protected func doSomething() {
> // ...
> }}
> // DerivedClass.swiftpublic class DerivedClass: BaseClass {
> protected override doSomething() {
> self.x = 10 * self.y
> }}
>
> If the member is declared as final then it will be visible but not can be
> overrided by the derived classes. Just like it works with other access
> levels.
> Value Types (structs, enums, etc.)
>
> Value types cannot have derived types. In this case the protected access
> level does not make sense and will not be allowed in their members.
> Protocols
>
> Protocols do not declare access level for their members. So the protected 
> access
> level is not applicable here.
> Extensions
>
> Extensions will not be able do be protected nor their members.
> Special Note
>
> The protected access level can only be applied to classes, structs and
> other types when nested inside other type. So the following code will not
> compile:
>
> // ERROR: A first level class cannot be protected.
> protected class MyProtectedClass {
> /// ...}
>
> But nested declarations will be allowed, so this code will compile:
>
> // We can declare a protected class (or struct, enum, etc.) if// and only if 
> they are nested inside other type.public class MyPublicClass {
> protected class MyProtectedClass {
> /// ...
> }}
> // Since `MyProtectedClass` is nested and protected we// can have access to 
> it here.public class MyDerivedClass: MyPublicClass {
> public func doSomething() {
> let c = MyProtectedClass()
>
> /// ...
> }}
>
> Impact on existing code
>
> The imported Cocoa frameworks may have annotations on the "Objective-C
> side" that will inform if one member is protected. If this will be case
> (for the layoutSubviews method, as example), only code accessing these
> now protected members outside the owner class and its derived classes will
> have to change (currently this can be considered an error, anyway).
>
> Any other code will be not impacted by this feature as it is new to the
> language.
> Alternatives considered
>
> Do not add the protected access level to the 

[swift-evolution] [Proposal] Protected Access Level

[Vanderlei Martinelli via swift-evolution]

Hello.


This is the first draft. I'd like to know your opinion about it.

(I know that this subject could have been discussed before. If so, please
indicate me the correct thread to follow and interact.)


Regards,

Vanderlei Martinelli


---


Introduction

Protected access level will enable entities to be used within the container
type and by derived types only.
Motivation

Today Swift has three access levels (public, internal and private), but
lacks a way to describe a member that can be only visible to its type or
derived types.

A common case is the UIView from UIKit. Many developers are tempted to make
this call:

view.layoutSubviews()

The documentation says: "You should not call this method directly. If you
want to force a layout update, call the setNeedsLayoutmethod instead to do
so prior to the next drawing update. If you want to update the layout of
your views immediately, call the layoutIfNeeded method."

But yes, you should call this method directly if you are subclassing the
view and needs to perform additional layout to its subviews ("subclasses
can override this method as needed"):

public override func layoutSubviews() {
// We are calling the super method directly here.
super.layoutSubviews()

// Do more adjustments to this view's subviews...}

So, yes, we can call this method directly when subclassing, but the Swift
compiler will not prevent you from do this when not subclassing or from any
other foreign class. It will not even issue a warning.

In Objective-C problems like this are usually "solved" my adding a kind of
"protected" header (.h) that is intended to be included only when the
developer is subclassing. In Swift we do not have headers, but we have the
new access level model. So, if the declaration of this method was...

protected func layoutSubviews()

... no one outside the class or derived classes would be allowed to call
this method directly.

Of course, there are other cases in the Cocoa frameworks and there are many
other cases when we are developing software in Swift that the protected access
level would be very usefull.
Proposed solution

Create the protected access level.
Detailed designReference Types (classes)

When declarated by a class the protected member will be visible to the
class itself and all the derived classes.

// BaseClass.swiftpublic class BaseClass {
public protected(set) var x = 20
protected let y = 10

protected func doSomething() {
// ...
}}
// DerivedClass.swiftpublic class DerivedClass: BaseClass {
protected override doSomething() {
self.x = 10 * self.y
}}

If the member is declared as final then it will be visible but not can be
overrided by the derived classes. Just like it works with other access
levels.
Value Types (structs, enums, etc.)

Value types cannot have derived types. In this case the protected access
level does not make sense and will not be allowed in their members.
Protocols

Protocols do not declare access level for their members. So the
protected access
level is not applicable here.
Extensions

Extensions will not be able do be protected nor their members.
Special Note

The protected access level can only be applied to classes, structs and
other types when nested inside other type. So the following code will not
compile:

// ERROR: A first level class cannot be protected.
protected class MyProtectedClass {
/// ...}

But nested declarations will be allowed, so this code will compile:

// We can declare a protected class (or struct, enum, etc.) if// and
only if they are nested inside other type.public class MyPublicClass {
protected class MyProtectedClass {
/// ...
}}
// Since `MyProtectedClass` is nested and protected we// can have
access to it here.public class MyDerivedClass: MyPublicClass {
public func doSomething() {
let c = MyProtectedClass()

/// ...
}}

Impact on existing code

The imported Cocoa frameworks may have annotations on the "Objective-C
side" that will inform if one member is protected. If this will be case
(for the layoutSubviews method, as example), only code accessing these now
protected members outside the owner class and its derived classes will have
to change (currently this can be considered an error, anyway).

Any other code will be not impacted by this feature as it is new to the
language.
Alternatives considered

Do not add the protected access level to the current model.


---
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution