Ok, I suppose that this design *basically* undoes the sealed by default thing, doesn’t it? :P lol. One of those days, I guess..
Sigh. Crawling away… l8r Sean > On Jul 1, 2016, at 1:16 PM, Sean Heber <[email protected]> wrote: > > Coming in late on this, but here’s my take guided by the principal of least > surprise (according to me): > > - everything is sealed within its module by default, no keyword > - use “public” to mean “exported out of the module, subclass/overridable” > - use “public(final)” to mean “exported out of the module, no subclassing or > overriding externally, but overriding and subclasses allowed internally” > - meaning of “final” does not change > - using “public final” then means the same as both public(final) and also > “final” internal to the module > - using “public(final) final” could be presented as an error with fixit since > it’s redundant > > Did I miss anything? > > l8r > Sean > > > >> On Jul 1, 2016, at 12:53 PM, John McCall via swift-evolution >> <[email protected]> wrote: >> >>> On Jul 1, 2016, at 10:51 AM, Michael Ilseman <[email protected]> wrote: >>> If “opened”, who or what did the opening? If “open” is like “extensible”, >>> then I would interpret “opened” to be like “extended”. >> >> Yeah, I would prefer "open" to "opened". >> >> John. >> >>> >>>> On Jul 1, 2016, at 10:35 AM, Leonardo Pessoa via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> The proposal was to use "sealed" so why not "opened"? I understand it >>>> may not be common to use "opened" as an adjective but from the >>>> dictionaries I consulted it is possible to. >>>> >>>> opened class MyViewController: UIViewController { >>>> opened func displayMe(_ me: person) { … } >>>> } >>>> >>>> On 1 July 2016 at 13:47, John McCall via swift-evolution >>>> <[email protected]> wrote: >>>>> On Jul 1, 2016, at 12:23 AM, Xiaodi Wu <[email protected]> wrote: >>>>> That starts to look an awful lot like a fifth access level just for >>>>> classes >>>>> (I know you're not proposing one, but it could start to look that way to a >>>>> user). I think there's much to be said for having the word public in front >>>>> of things that are public. Unless, of course, your strawman keyword is a >>>>> much maligned compound word that begins with "public", like >>>>> "publicoverridable". >>>>> >>>>> >>>>> I would also prefer a single keyword if the word implies something about >>>>> accessibility. "open" does that, although using it here would conflict >>>>> with >>>>> its potential use on enums unless we required all cases within the >>>>> defining >>>>> module to be present in the enum declaration rather than extensions. >>>>> >>>>> I don't think we'd ever use a compound keyword that starts with public; >>>>> we'd >>>>> just separate them and say that the second half can only be present on a >>>>> public declaration, or do this parenthesized syntax. >>>>> >>>>> John. >>>>> >>>>> >>>>> On Fri, Jul 1, 2016 at 01:54 Brent Royal-Gordon <[email protected]> >>>>> wrote: >>>>>> >>>>>>> If we're going to go along those lines, we should just use >>>>>>> public(subclassable) and public(overridable). We can fall back on >>>>>>> those if >>>>>>> necessary; I would just like to continue looking for better >>>>>>> alternatives. >>>>>> >>>>>> I would prefer to have a *single* keyword which meant both public and >>>>>> overridable. That would minimize the impact of this feature—instead of >>>>>> writing: >>>>>> >>>>>> public class MyViewController: UIViewController { >>>>>> public func displayMe(_ me: person) { … } >>>>>> } >>>>>> >>>>>> You'd write (strawman keyword): >>>>>> >>>>>> openseason class MyViewController: UIViewController { >>>>>> openseason func displayMe(_ me: person) { … } >>>>>> } >>>>>> >>>>>> And then `MyViewController` could be subclassed, and `displayMe` >>>>>> overridden. >>>>>> >>>>>> -- >>>>>> Brent Royal-Gordon >>>>>> Architechies >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> [email protected] >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
