> On 15 Jul 2016, at 12:46, Haravikk via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>> On 14 Jul 2016, at 22:39, Chris Lattner via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>> To sum this all up, the core team is rejecting this proposal and requesting
>> a revision to change the concrete syntax to “public open class Foo” instead
>> of “subclassable class Foo".
>
> Minor point, but if we're going with the idea of public open and public final
> for declaration, is it worth re-raising the idea of bracketed accessibility
> modifiers? When fileprivate vs private was being discussed I was heavily in
> favour of private(file), private(scope) and private(module) (plus
> private(type) if we get that) to avoid polluting the language with more
> accessibility-specific keywords. This seems like a good time to mention it
> again, as we're now looking at even more keyword pollution:
>
> public(open)
> public(sealed) // Probably not actually defined, but the
> default for a plain "public" declaration
> public(final)
> private(module) // Replaces internal
> private(file)
> private(scope) // Default for plain private
>
> If we get a private(type) that's seven different keyword combinations for one
> feature, so I still very much prefer it being reduced to just public/private
> plus a modifier ;)
I think it makes sense to have it bracketed, but I’m not sure about replacing
internal/private/fileprivate.
I’m thinking it should be:
public(open) class XYZ {}
public internal(open) class XYZ {}
Etc
I view it along the same lines as mutability for properties - I.e. “public
private(set)”.
In that case, it would make sense to do the same for overridable members. You
can only override members of an open class, so it makes sense to just use the
“open” name in both places to denote that you may create your own versions of
these things. An overriden method “is” an instance of the original method in
the same way a derived class “is” an instance of its base class. My overriden
“viewDidLoad” or whatever “is” the viewDidLoad for this class.
So to summarise, I think it should look like this (just showing off features,
obviously it wouldn’t be okay to have public(open) members in an internal(open)
class...):
public internal(open) XYZ {
public private(set) var nonOverridable : Something
public(open) var overridable : Something
public(open) private(set) var getterOverridable : UIColor? // In this
case, the subclass can provide a value in its getter (e.g. backgroundColor) -
// if it doesn’t (I.e. The type is optional), the base class
may have a default value stored. I’m not sure… it’s an awkward one.
public(open) func overridePointForSubclasses() {
// Don’t you see so many functions named or documented like this? It’s
nice that we’ll have them marked-up explicitly.
}
}
Karl_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
