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?
-----Original Message-----
From: "Vanderlei Martinelli via swift-evolution" <[email protected]>
Sent: 29/05/2016 06:56 PM
To: "swift-evolution" <[email protected]>
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 <[email protected]>
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�
[The entire original message is not included.]_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
