Also, even if the sample code with the 3 extensions might looks ok, think that
if you’re working on a 300 classes project, declaring 900 extensions seems a
crazy thing to do. I would not have to do this on a big project.
@Charlie: Agree with you, on second thought, the implication of extending the
use of access modifier blocks to functions and protocols seems a bit tricky and
could increase the indentation level of the code in an annoying way. So, I
would go with a proposal limited to vars/constants/properties items.
> Le 14 juin 2016 à 23:46, Charlie Monroe <char...@charliemonroe.net> a écrit :
>
> Your approach has a major flaw: methods from extensions can't be overridden
> (at least for now). As long as you want to your controller to be subclassed
> and allow overriding your public/internal methods, you need to move them from
> extensions to the main class scope. Which simply sucks and may be fine for
> final classes (or classes that you don't plan on subclassing), but is in no
> way a good way to design a root class which is meant to be subclassed.
>
> I am kind of on and off on this proposal - I like the way you can group vars
> together based on access control, but I'd leave it at that, not extending it
> to methodsm since it would introduce horizontal space issues (code starting
> at indentation level 4).
>
>> On Jun 14, 2016, at 10:18 PM, David Hart <da...@hartbit.com> wrote:
>>
>> I dont agree. I think extensions serve this purpose very well. Here is what
>> I do:
>>
>> I start with the type declaration only containing properties (public or
>> private). I then create one extension per access level required and one per
>> protocol conformance and per superclass overrides. We get:
>>
>> class MyViewController: UIViewController {
>> public let publicProp: Int = 0
>> @IBOutlet private var tableView: UITableView!
>> }
>>
>> //MARK: - Public
>> public extension MyViewController {
>> // Public functions
>> }
>>
>> //MARK: - UIViewController
>> public extension MyViewController {
>> override func viewDidLoad() {
>> }
>> }
>>
>> //MARK: UITableViewDataSource
>> extension MyViewController: UITableViewDataSource {
>> override func numberOfSectionsInTableView(tableView: UITableView) {
>> return 1
>> }
>> }
>>
>> //MARK: Private
>> private extension MyViewController {
>> // Private functions
>> }
>>
>>> On 13 Jun 2016, at 01:14, Raphaël Wach via swift-evolution
>>> <swift-evolution@swift.org> wrote:
>>>
>>> Yes, extensions serve a different purposes. It doesn’t seem right for me to
>>> just split every class content into 3 different extensions only to group
>>> together items with a similar access level.
>>> It would just make the codebase of a framework more messy. Access modifier
>>> block allows to not break the structure of a class but make it more easy to
>>> organize, to write and to read which seems nice for our « write less,
>>> achieve more » new favorite language, Swift. :)
>>>
>>> Raph
>>>
>>>
>>>
>>>> Le 13 juin 2016 à 10:04, Charlie Monroe <char...@charliemonroe.net> a
>>>> écrit :
>>>>
>>>> Extensions can't have stored properties.
>>>>
>>>>> On Jun 13, 2016, at 9:59 AM, Robert Widmann via swift-evolution
>>>>> <swift-evolution@swift.org> wrote:
>>>>>
>>>>> What does this do that breaking a structure down into local extensions
>>>>> with the appropriate level of access control doesn't?
>>>>>
>>>>> ~Robert Widmann
>>>>>
>>>>> 2016/06/13 0:55、Raphaël Wach via swift-evolution
>>>>> <swift-evolution@swift.org> のメッセージ:
>>>>>
>>>>>> Hello Swifters,
>>>>>>
>>>>>> While working on some framework programming, I had this idea that I
>>>>>> would like to share with you.
>>>>>> If some other people like it, I would be more than happy to write a
>>>>>> proposal.
>>>>>>
>>>>>> Here is a little draft I wrote as a starting point to discuss.
>>>>>> Sorry if there is mistakes, I am not an english native speaker.
>>>>>> Thank you for your feedback.
>>>>>>
>>>>>> ————————————————————————————————————
>>>>>>
>>>>>> Swift proposal: Access modifier blocks
>>>>>>
>>>>>> This proposal introduces a refinement of the way to define access
>>>>>> modifier and visibility scope.
>>>>>>
>>>>>> The current keywords private, internal and public are nice, simple to
>>>>>> use and makes sense. But, especially in the context of framework
>>>>>> development, it can quickly becomes messy and confusing to define the
>>>>>> visibility for each member variable, function or enum. Also it takes
>>>>>> more time to write and is not ideal to visualize the public interface of
>>>>>> a class.
>>>>>>
>>>>>> If a class A has only a few members, that’s ok to write
>>>>>>
>>>>>> class A {
>>>>>> public var member1: Int
>>>>>> var member2: Int
>>>>>> private var member3: Int
>>>>>> }
>>>>>>
>>>>>> With a bigger class B, it will looks far less nice
>>>>>>
>>>>>> class B {
>>>>>> public var member1: Int
>>>>>> var member2: Int
>>>>>> private var member3: Int
>>>>>> public var member4: Int
>>>>>> var member5: Int
>>>>>> private var member6: Int
>>>>>> public var member7: Int
>>>>>> var member8: Int
>>>>>> private var member9: Int
>>>>>> public var member10: Int
>>>>>> private var member11: Int
>>>>>> var member12: Int
>>>>>> public var member13: Int
>>>>>> var member14: Int
>>>>>> private var member15: Int
>>>>>> }
>>>>>>
>>>>>> And now, it’s really messy, takes more time to write and we need to
>>>>>> think twice to visualize what could be the public interface of our
>>>>>> framework.
>>>>>>
>>>>>> The purpose of this proposal is to allow the definition of the access
>>>>>> modifiers for a block of declarations.
>>>>>> Then our class B could be:
>>>>>>
>>>>>> class B {
>>>>>> // Ok then this is part of the public interface of my framework
>>>>>> public {
>>>>>> var member1: Int
>>>>>> var member4: Int
>>>>>> var member7: Int
>>>>>> var member10: Int
>>>>>> var member13: Int
>>>>>> }
>>>>>> // This can be used anywhere in my framework
>>>>>> internal {
>>>>>> var member2: Int
>>>>>> var member5: Int
>>>>>> var member8: Int
>>>>>> var member12: Int
>>>>>> var member14: Int
>>>>>> }
>>>>>> // Here remains my private stuff. Don’t touch it ! Leave me alone ! My
>>>>>> preciouuusss
>>>>>> private {
>>>>>> var member3: Int
>>>>>> var member6: Int
>>>>>> var member9: Int
>>>>>> var member11: Int
>>>>>> var member15: Int
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> It increases readability, avoid to write many times the same keywords,
>>>>>> which is quiet boring, and helps visualizing the architecture of the
>>>>>> framework by highlighting what can create a dependency with other
>>>>>> classes inside the framework and with code outside of the framework.
>>>>>>
>>>>>> It might also be useful in protocols. For exemple, a protocol could
>>>>>> define a set of methods that can be called only inside the framework and
>>>>>> another public one that can be called from outside of the framework.
>>>>>> Classes defined outside of the framework could only implement the public
>>>>>> stuff in the protocol.
>>>>>>
>>>>>> It would have no impact on the existing code as the existing
>>>>>> private/internal/public on every single line would still work outside of
>>>>>> an access modifier block so developers could move to use this smoothly.
>>>>>>
>>>>>> ————————————————————————————————————
>>>>>>
>>>>>> Please, let me know if you like the idea.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Raph
>>>>>> _______________________________________________
>>>>>> 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
>>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
