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> 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�
>>>
>>
>> [The entire original message is not included.]
>>
>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
