[Pitch] consistent public access modifiers

Rien · February 15, 2017, 4:35pm

Our philosophy in general, however, is to default to the behavior which preserves the most flexibility for the library designer.

Actually, I thought the philosophy was to preserver type safety. When did that change?

Also, when was the library designer prioritised ahead of the application developer?

Both open and non-open classes are common, but we chose to give non-open classes the `public` keyword because that's the flexibility-preserving option.

No it isn’t, it’s the flexibility restricting option. The consumer of an open class can subclass it. The consumer of a public class cannot subclass it. How is the second more flexible than the first?

It reduces complexity for the library author by allowing them to opt-out of the complexity involved in supporting unknown, user-defined subclasses. It is important to allow libraries to have this flexibility. They are free to declare a class `open` if they want to allow subclassing. It’s even possibly for a library to declare all classes `open` if it wishes to do so. But *requiring* that would reduce the design space libraries are allowed to explore and / or introduce fragility by moving the subclass restriction to a comment.

Why would a library author want to prohibit subclasses?
A library user can always wrap the class and subclass the wrapper.

This is composition, not inheritance. The most important difference is that a wrapper cannot override methods, it can only wrap and / or forward them. This means that when the superclass calls a method on `self` that method *always* invokes its version of that method rather than a subclass override. This is a very important difference.

Agreed, however that does not answer the question why would a library developer want to disallow subclassing?
I do not see a use case for that. I.e. a feature that cannot be implemented without it. (without “open”)

The feature it enables is more robust libraries and the ability for library authors to better reason about their code. You may not find this benefit enough to be worth a language feature, but many of us do.

You start of with a claim “more robust libraries”.
I would really like to know the “how” of that. How does it make a library more robust?

I do write libraries myself, and if there is something I am missing, I very much would like to know.

Regards,
Rien.

···

On 15 Feb 2017, at 17:02, Matthew Johnson <matthew@anandabits.com> wrote:

On Feb 15, 2017, at 9:59 AM, Rien <Rien@Balancingrock.nl> wrote:

On 15 Feb 2017, at 16:45, Matthew Johnson <matthew@anandabits.com> wrote:

On Feb 15, 2017, at 9:35 AM, Rien <Rien@Balancingrock.nl> wrote:

On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution <swift-evolution@swift.org> wrote:

On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

Rien.

There are cases where subclassing does not make sense. And thus preventing subclasses adds information for those users that don’t RTFM. But that imo is not worth the impact extra complexity places on all other users.

Rien.

_______________________________________________
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

anandabits · February 15, 2017, 4:45pm

Our philosophy in general, however, is to default to the behavior which preserves the most flexibility for the library designer.

Actually, I thought the philosophy was to preserver type safety. When did that change?

Also, when was the library designer prioritised ahead of the application developer?

Both open and non-open classes are common, but we chose to give non-open classes the `public` keyword because that's the flexibility-preserving option.

No it isn’t, it’s the flexibility restricting option. The consumer of an open class can subclass it. The consumer of a public class cannot subclass it. How is the second more flexible than the first?

It reduces complexity for the library author by allowing them to opt-out of the complexity involved in supporting unknown, user-defined subclasses. It is important to allow libraries to have this flexibility. They are free to declare a class `open` if they want to allow subclassing. It’s even possibly for a library to declare all classes `open` if it wishes to do so. But *requiring* that would reduce the design space libraries are allowed to explore and / or introduce fragility by moving the subclass restriction to a comment.

Why would a library author want to prohibit subclasses?
A library user can always wrap the class and subclass the wrapper.

This is composition, not inheritance. The most important difference is that a wrapper cannot override methods, it can only wrap and / or forward them. This means that when the superclass calls a method on `self` that method *always* invokes its version of that method rather than a subclass override. This is a very important difference.

Agreed, however that does not answer the question why would a library developer want to disallow subclassing?
I do not see a use case for that. I.e. a feature that cannot be implemented without it. (without “open”)

The feature it enables is more robust libraries and the ability for library authors to better reason about their code. You may not find this benefit enough to be worth a language feature, but many of us do.

You start of with a claim “more robust libraries”.
I would really like to know the “how” of that. How does it make a library more robust?

I do write libraries myself, and if there is something I am missing, I very much would like to know.

This topic was well explored during the discussion and review of the proposal that introduced `open`. If you would really like to know I suggest you take some time to read through that discussion.

···

On Feb 15, 2017, at 10:35 AM, Rien <Rien@Balancingrock.nl> wrote:

On 15 Feb 2017, at 17:02, Matthew Johnson <matthew@anandabits.com> wrote:

On Feb 15, 2017, at 9:59 AM, Rien <Rien@Balancingrock.nl> wrote:

On 15 Feb 2017, at 16:45, Matthew Johnson <matthew@anandabits.com> wrote:

On Feb 15, 2017, at 9:35 AM, Rien <Rien@Balancingrock.nl> wrote:

On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution <swift-evolution@swift.org> wrote:

On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

Regards,
Rien.

Rien.

There are cases where subclassing does not make sense. And thus preventing subclasses adds information for those users that don’t RTFM. But that imo is not worth the impact extra complexity places on all other users.

Rien.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Rien · February 15, 2017, 4:50pm

A short example where I personally wanted a public-but-not-open protocol:

public protocol SubscriptParameterType {

    // This property was needed to prevent the client from breaking
    // the library by conforming to the protocol, but I'd like to
    // keep it invisible for the client, or even better prevent the
    // client from conforming to the protocol.
    var parameter: Document.SubscriptParameter { get }
}

extension Document {

    public enum SubscriptParameter {

        case string(String)
        case integer(Int)
    }
}

extension String : SubscriptParameterType {

    public var parameter: Document.SubscriptParameter {

        return .string(self)
    }
}

extension Int : SubscriptParameterType {

    public var parameter: Document.SubscriptParameter {

        return .integer(self)
    }
}

// Somewhere inside the `Document` type
public subscript(firstKey: String, parameters: SubscriptParameterType...) -> Value? { … }

That implementation enables more safe queries of my Document type like document["key1", intIndexInstance, stringKeyInstance, 10, "key"] rather than document["key1/\(intIndexInstance)/\(stringKeyInstance)/10/key”]

I see how that makes queries better.
However what I do not see is how making the protocol “open” would make this less safe.
(I do not see a reason to make it open either, but that is not the question)

It may be obvious to everyone else, but I don’t see it. Am I suffering from a brain freeze?.

Regards,
Rien.

···

On 15 Feb 2017, at 17:22, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

.

--
Adrian Zubarev
Sent with Airmail

Am 15. Februar 2017 um 17:03:32, Matthew Johnson via swift-evolution (swift-evolution@swift.org) schrieb:

On Feb 15, 2017, at 9:59 AM, Rien <Rien@Balancingrock.nl> wrote:

On 15 Feb 2017, at 16:45, Matthew Johnson <matthew@anandabits.com> wrote:

On Feb 15, 2017, at 9:35 AM, Rien <Rien@Balancingrock.nl> wrote:

On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution <swift-evolution@swift.org> wrote:

On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

Our philosophy in general, however, is to default to the behavior which preserves the most flexibility for the library designer.

Actually, I thought the philosophy was to preserver type safety. When did that change?

Also, when was the library designer prioritised ahead of the application developer?

Both open and non-open classes are common, but we chose to give non-open classes the `public` keyword because that's the flexibility-preserving option.

No it isn’t, it’s the flexibility restricting option. The consumer of an open class can subclass it. The consumer of a public class cannot subclass it. How is the second more flexible than the first?

It reduces complexity for the library author by allowing them to opt-out of the complexity involved in supporting unknown, user-defined subclasses. It is important to allow libraries to have this flexibility. They are free to declare a class `open` if they want to allow subclassing. It’s even possibly for a library to declare all classes `open` if it wishes to do so. But *requiring* that would reduce the design space libraries are allowed to explore and / or introduce fragility by moving the subclass restriction to a comment.

Why would a library author want to prohibit subclasses?
A library user can always wrap the class and subclass the wrapper.

This is composition, not inheritance. The most important difference is that a wrapper cannot override methods, it can only wrap and / or forward them. This means that when the superclass calls a method on `self` that method *always* invokes its version of that method rather than a subclass override. This is a very important difference.

Agreed, however that does not answer the question why would a library developer want to disallow subclassing?
I do not see a use case for that. I.e. a feature that cannot be implemented without it. (without “open”)

The feature it enables is more robust libraries and the ability for library authors to better reason about their code. You may not find this benefit enough to be worth a language feature, but many of us do.

Rien.

There are cases where subclassing does not make sense. And thus preventing subclasses adds information for those users that don’t RTFM. But that imo is not worth the impact extra complexity places on all other users.

Rien.

_______________________________________________
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

David_Smith · February 16, 2017, 2:45am

Our philosophy in general, however, is to default to the behavior which preserves the most flexibility for the library designer.

Actually, I thought the philosophy was to preserver type safety. When did that change?

Also, when was the library designer prioritised ahead of the application developer?

Both open and non-open classes are common, but we chose to give non-open classes the `public` keyword because that's the flexibility-preserving option.

No it isn’t, it’s the flexibility restricting option. The consumer of an open class can subclass it. The consumer of a public class cannot subclass it. How is the second more flexible than the first?

It reduces complexity for the library author by allowing them to opt-out of the complexity involved in supporting unknown, user-defined subclasses. It is important to allow libraries to have this flexibility. They are free to declare a class `open` if they want to allow subclassing. It’s even possibly for a library to declare all classes `open` if it wishes to do so. But *requiring* that would reduce the design space libraries are allowed to explore and / or introduce fragility by moving the subclass restriction to a comment.

Why would a library author want to prohibit subclasses?
A library user can always wrap the class and subclass the wrapper.

This is composition, not inheritance. The most important difference is that a wrapper cannot override methods, it can only wrap and / or forward them. This means that when the superclass calls a method on `self` that method *always* invokes its version of that method rather than a subclass override. This is a very important difference.

Agreed, however that does not answer the question why would a library developer want to disallow subclassing?
I do not see a use case for that. I.e. a feature that cannot be implemented without it. (without “open”)

The feature it enables is more robust libraries and the ability for library authors to better reason about their code. You may not find this benefit enough to be worth a language feature, but many of us do.

You start of with a claim “more robust libraries”.
I would really like to know the “how” of that. How does it make a library more robust?

I do write libraries myself, and if there is something I am missing, I very much would like to know.

Regards,
Rien.

The usual thing I've run into in practice follows this general pattern:

• A non-threadsafe class is introduced
• Years or decades pass
• Someone (me) tries to make the class threadsafe by adding locking
• In the intervening years, subclasses have been introduced that override methods now called while holding a lock, and reentrantly call back into other methods that take the lock

I've worked around this using recursive mutexes in some cases, but in more extreme cases the subclass synchronously called out to another thread, and that thread reentered the lock.

A defensive rule I've adopted in some new code is "public methods are not allowed to call other public methods", which avoids reentrancy issues, but also makes subclassing somewhat useless since the work is being done by private non-overridable methods.

David

···

On Feb 15, 2017, at 8:35 AM, Rien via swift-evolution <swift-evolution@swift.org> wrote:

On 15 Feb 2017, at 17:02, Matthew Johnson <matthew@anandabits.com> wrote:

On Feb 15, 2017, at 9:59 AM, Rien <Rien@Balancingrock.nl> wrote:

On 15 Feb 2017, at 16:45, Matthew Johnson <matthew@anandabits.com> wrote:

On Feb 15, 2017, at 9:35 AM, Rien <Rien@Balancingrock.nl> wrote:

On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution <swift-evolution@swift.org> wrote:

On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

Rien.

There are cases where subclassing does not make sense. And thus preventing subclasses adds information for those users that don’t RTFM. But that imo is not worth the impact extra complexity places on all other users.

Rien.

_______________________________________________
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

Rien · February 15, 2017, 5:56pm

Our philosophy in general, however, is to default to the behavior which preserves the most flexibility for the library designer.

Actually, I thought the philosophy was to preserver type safety. When did that change?

Also, when was the library designer prioritised ahead of the application developer?

Both open and non-open classes are common, but we chose to give non-open classes the `public` keyword because that's the flexibility-preserving option.

No it isn’t, it’s the flexibility restricting option. The consumer of an open class can subclass it. The consumer of a public class cannot subclass it. How is the second more flexible than the first?

It reduces complexity for the library author by allowing them to opt-out of the complexity involved in supporting unknown, user-defined subclasses. It is important to allow libraries to have this flexibility. They are free to declare a class `open` if they want to allow subclassing. It’s even possibly for a library to declare all classes `open` if it wishes to do so. But *requiring* that would reduce the design space libraries are allowed to explore and / or introduce fragility by moving the subclass restriction to a comment.

Why would a library author want to prohibit subclasses?
A library user can always wrap the class and subclass the wrapper.

This is composition, not inheritance. The most important difference is that a wrapper cannot override methods, it can only wrap and / or forward them. This means that when the superclass calls a method on `self` that method *always* invokes its version of that method rather than a subclass override. This is a very important difference.

Agreed, however that does not answer the question why would a library developer want to disallow subclassing?
I do not see a use case for that. I.e. a feature that cannot be implemented without it. (without “open”)

The feature it enables is more robust libraries and the ability for library authors to better reason about their code. You may not find this benefit enough to be worth a language feature, but many of us do.

You start of with a claim “more robust libraries”.
I would really like to know the “how” of that. How does it make a library more robust?

I do write libraries myself, and if there is something I am missing, I very much would like to know.

This topic was well explored during the discussion and review of the proposal that introduced `open`. If you would really like to know I suggest you take some time to read through that discussion.

I did (proposal 117), while it was mentioned a few times “if not carefully designed for subclassing” there is no example on how open vs public prevents anything.

Mind you, it could be argued that the default of “internal” instead of “open” can prevent something (though I still don’t know what). But adding “open” does imo not prevent anything.

Besides: a monkey with a tool is still a monkey.

I.e. devs that now start using “open” vs “public” because it all is a hassle to figure out what should be “internal”, “public” or “open” will still make the same errors (which ones?) as before.
Thus while there is a lot of bad code around (partly mine!) that does not disappear because the default is not “not subclassable”.

(PS: I am still trying to get my head around Adrian’s example)

Regards,
Rien.

···

On 15 Feb 2017, at 17:45, Matthew Johnson <matthew@anandabits.com> wrote:

On Feb 15, 2017, at 10:35 AM, Rien <Rien@Balancingrock.nl> wrote:

On 15 Feb 2017, at 17:02, Matthew Johnson <matthew@anandabits.com> wrote:

On Feb 15, 2017, at 9:59 AM, Rien <Rien@Balancingrock.nl> wrote:

On 15 Feb 2017, at 16:45, Matthew Johnson <matthew@anandabits.com> wrote:

On Feb 15, 2017, at 9:35 AM, Rien <Rien@Balancingrock.nl> wrote:

On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution <swift-evolution@swift.org> wrote:

On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

Regards,
Rien.

Rien.

There are cases where subclassing does not make sense. And thus preventing subclasses adds information for those users that don’t RTFM. But that imo is not worth the impact extra complexity places on all other users.

Rien.

_______________________________________________
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

DevAndArtist · February 15, 2017, 5:09pm

As I already said:

To make that feature happen, we need the protocol to be public (regardless if you can conform to it or not).
Today you can conform to every protocol because in reality they are open today.
If we remove the property requirement from the protocol the client can conform it to any type and break my API by calling the subscript with a wrong type: document["something", NSObject()] (assuming extension NSObject : SubscriptParameterType).
That forces me to create a requirement for the protocol which solves the issue in my cases, however there might exist other issues, which could be far more complicated than mine is.
That also implies I have make the enum public.
Which follows by the fact that I’m creating unnecessary copy operations to wrap every instance that conforms to my protocol into an enum case. From internal API perspective I also have to unwrap the enum case.
Instead if we had consistent public vs. open behavior, I could make the protocol public (but-not-open), remove the requirement from it completely, remove the enum completely and simply cast to Int or String because as the author of the library I would know that the client won’t be able to conform to my protocol.

Importing my library will show the client only this:

extension Int : SubscriptParameterType {}
extension String : SubscriptParameterType {}

···

--
Adrian Zubarev
Sent with Airmail

Am 15. Februar 2017 um 17:50:41, Rien (rien@balancingrock.nl) schrieb:

On 15 Feb 2017, at 17:22, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

A short example where I personally wanted a public-but-not-open protocol:

public protocol SubscriptParameterType {

// This property was needed to prevent the client from breaking
// the library by conforming to the protocol, but I'd like to
// keep it invisible for the client, or even better prevent the
// client from conforming to the protocol.
var parameter: Document.SubscriptParameter { get }
}

extension Document {

public enum SubscriptParameter {

case string(String)
case integer(Int)
}
}

extension String : SubscriptParameterType {

public var parameter: Document.SubscriptParameter {

return .string(self)
}
}

extension Int : SubscriptParameterType {

public var parameter: Document.SubscriptParameter {

return .integer(self)
}
}

// Somewhere inside the `Document` type
public subscript(firstKey: String, parameters: SubscriptParameterType...) -> Value? { … }

That implementation enables more safe queries of my Document type like document["key1", intIndexInstance, stringKeyInstance, 10, "key"] rather than document["key1/\(intIndexInstance)/\(stringKeyInstance)/10/key”]

I see how that makes queries better.
However what I do not see is how making the protocol “open” would make this less safe.
(I do not see a reason to make it open either, but that is not the question)

It may be obvious to everyone else, but I don’t see it. Am I suffering from a brain freeze?.

Regards,
Rien.

.

--
Adrian Zubarev
Sent with Airmail

Am 15. Februar 2017 um 17:03:32, Matthew Johnson via swift-evolution (swift-evolution@swift.org) schrieb:

On Feb 15, 2017, at 9:59 AM, Rien <Rien@Balancingrock.nl> wrote:

On 15 Feb 2017, at 16:45, Matthew Johnson <matthew@anandabits.com> wrote:

On Feb 15, 2017, at 9:35 AM, Rien <Rien@Balancingrock.nl> wrote:

On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution <swift-evolution@swift.org> wrote:

On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

Our philosophy in general, however, is to default to the behavior which preserves the most flexibility for the library designer.

Actually, I thought the philosophy was to preserver type safety. When did that change?

Also, when was the library designer prioritised ahead of the application developer?

Both open and non-open classes are common, but we chose to give non-open classes the `public` keyword because that's the flexibility-preserving option.

No it isn’t, it’s the flexibility restricting option. The consumer of an open class can subclass it. The consumer of a public class cannot subclass it. How is the second more flexible than the first?

It reduces complexity for the library author by allowing them to opt-out of the complexity involved in supporting unknown, user-defined subclasses. It is important to allow libraries to have this flexibility. They are free to declare a class `open` if they want to allow subclassing. It’s even possibly for a library to declare all classes `open` if it wishes to do so. But *requiring* that would reduce the design space libraries are allowed to explore and / or introduce fragility by moving the subclass restriction to a comment.

Why would a library author want to prohibit subclasses?
A library user can always wrap the class and subclass the wrapper.

This is composition, not inheritance. The most important difference is that a wrapper cannot override methods, it can only wrap and / or forward them. This means that when the superclass calls a method on `self` that method *always* invokes its version of that method rather than a subclass override. This is a very important difference.

Agreed, however that does not answer the question why would a library developer want to disallow subclassing?
I do not see a use case for that. I.e. a feature that cannot be implemented without it. (without “open”)

The feature it enables is more robust libraries and the ability for library authors to better reason about their code. You may not find this benefit enough to be worth a language feature, but many of us do.

Rien.

There are cases where subclassing does not make sense. And thus preventing subclasses adds information for those users that don’t RTFM. But that imo is not worth the impact extra complexity places on all other users.

Rien.

_______________________________________________
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

DevAndArtist · February 15, 2017, 6:15pm

I’ll try again to make it a little bit more simpler.

Assume we want to implement my feature to support document["string_literal", stringInstance, integerInstance, 42] where the first parameter type is always a String but the types follow afterward are either a String or an Int (literals should be supported too).

// Module A
// Today only `public` is allowed on protocols.
// `public protocol` means almost the same as `open class`.
// One is 'you can conform to it outside module A'
// the other is 'you can subclass to it outside module A'

// First idea
public SubscriptParameterType {}
extension Int : SubscriptParameterType {}
extension String : SubscriptParameterType {}

extension Document {

    public subscript(firstKey: String, parameters: SubscriptParameterType...) -> Value? {

        // CAST any instance of `SubscriptParameterType` to Int or String
    }
}

// Module B
extension NSObject : SubscriptParameterType {}

// Lets try breaking module A
document["test", NSObject()] // Runtime error, because something unexpected happened in module A

// The reason is we let the client (module B) the ability to conform to our type without any requirements.

// To solve that issue we need TODAY a requirement on our protocol `SubscriptParameterType` (see my previous post)
// I already mentioned that the workaround creates unnecessary boilerplate in my library.

// We could clean everything up iff we had consistent `public` vs. `open` behavior. I will use `pulic-but-not-open` and `open` annotation now.

pulic-but-not-open SubscriptParameterType {}
extension Int : SubscriptParameterType {}
extension String : SubscriptParameterType {}

// Module B
extension NSObject : SubscriptParameterType {} // Error, `SubscriptParameterType` is closed and cannot be conformed to outside module A!!
This feature is ridiculously powerful.

···

--
Adrian Zubarev
Sent with Airmail

Am 15. Februar 2017 um 18:57:50, Rien via swift-evolution (swift-evolution@swift.org) schrieb:

On 15 Feb 2017, at 17:45, Matthew Johnson <matthew@anandabits.com> wrote:

On Feb 15, 2017, at 10:35 AM, Rien <Rien@Balancingrock.nl> wrote:

On 15 Feb 2017, at 17:02, Matthew Johnson <matthew@anandabits.com> wrote:

On Feb 15, 2017, at 9:59 AM, Rien <Rien@Balancingrock.nl> wrote:

On 15 Feb 2017, at 16:45, Matthew Johnson <matthew@anandabits.com> wrote:

On Feb 15, 2017, at 9:35 AM, Rien <Rien@Balancingrock.nl> wrote:

On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution <swift-evolution@swift.org> wrote:

On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

Our philosophy in general, however, is to default to the behavior which preserves the most flexibility for the library designer.

Actually, I thought the philosophy was to preserver type safety. When did that change?

Also, when was the library designer prioritised ahead of the application developer?

Both open and non-open classes are common, but we chose to give non-open classes the `public` keyword because that's the flexibility-preserving option.

No it isn’t, it’s the flexibility restricting option. The consumer of an open class can subclass it. The consumer of a public class cannot subclass it. How is the second more flexible than the first?

It reduces complexity for the library author by allowing them to opt-out of the complexity involved in supporting unknown, user-defined subclasses. It is important to allow libraries to have this flexibility. They are free to declare a class `open` if they want to allow subclassing. It’s even possibly for a library to declare all classes `open` if it wishes to do so. But *requiring* that would reduce the design space libraries are allowed to explore and / or introduce fragility by moving the subclass restriction to a comment.

Why would a library author want to prohibit subclasses?
A library user can always wrap the class and subclass the wrapper.

This is composition, not inheritance. The most important difference is that a wrapper cannot override methods, it can only wrap and / or forward them. This means that when the superclass calls a method on `self` that method *always* invokes its version of that method rather than a subclass override. This is a very important difference.

Agreed, however that does not answer the question why would a library developer want to disallow subclassing?
I do not see a use case for that. I.e. a feature that cannot be implemented without it. (without “open”)

The feature it enables is more robust libraries and the ability for library authors to better reason about their code. You may not find this benefit enough to be worth a language feature, but many of us do.

You start of with a claim “more robust libraries”.
I would really like to know the “how” of that. How does it make a library more robust?

I do write libraries myself, and if there is something I am missing, I very much would like to know.

This topic was well explored during the discussion and review of the proposal that introduced `open`. If you would really like to know I suggest you take some time to read through that discussion.

I did (proposal 117), while it was mentioned a few times “if not carefully designed for subclassing” there is no example on how open vs public prevents anything.

Mind you, it could be argued that the default of “internal” instead of “open” can prevent something (though I still don’t know what). But adding “open” does imo not prevent anything.

Besides: a monkey with a tool is still a monkey.

I.e. devs that now start using “open” vs “public” because it all is a hassle to figure out what should be “internal”, “public” or “open” will still make the same errors (which ones?) as before.
Thus while there is a lot of bad code around (partly mine!) that does not disappear because the default is not “not subclassable”.

(PS: I am still trying to get my head around Adrian’s example)

Regards,
Rien.

Regards,
Rien.

Rien.

There are cases where subclassing does not make sense. And thus preventing subclasses adds information for those users that don’t RTFM. But that imo is not worth the impact extra complexity places on all other users.

Rien.

_______________________________________________
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

Rien · February 16, 2017, 6:57am

Our philosophy in general, however, is to default to the behavior which preserves the most flexibility for the library designer.

Actually, I thought the philosophy was to preserver type safety. When did that change?

Also, when was the library designer prioritised ahead of the application developer?

Both open and non-open classes are common, but we chose to give non-open classes the `public` keyword because that's the flexibility-preserving option.

No it isn’t, it’s the flexibility restricting option. The consumer of an open class can subclass it. The consumer of a public class cannot subclass it. How is the second more flexible than the first?

It reduces complexity for the library author by allowing them to opt-out of the complexity involved in supporting unknown, user-defined subclasses. It is important to allow libraries to have this flexibility. They are free to declare a class `open` if they want to allow subclassing. It’s even possibly for a library to declare all classes `open` if it wishes to do so. But *requiring* that would reduce the design space libraries are allowed to explore and / or introduce fragility by moving the subclass restriction to a comment.

Why would a library author want to prohibit subclasses?
A library user can always wrap the class and subclass the wrapper.

This is composition, not inheritance. The most important difference is that a wrapper cannot override methods, it can only wrap and / or forward them. This means that when the superclass calls a method on `self` that method *always* invokes its version of that method rather than a subclass override. This is a very important difference.

Agreed, however that does not answer the question why would a library developer want to disallow subclassing?
I do not see a use case for that. I.e. a feature that cannot be implemented without it. (without “open”)

The feature it enables is more robust libraries and the ability for library authors to better reason about their code. You may not find this benefit enough to be worth a language feature, but many of us do.

You start of with a claim “more robust libraries”.
I would really like to know the “how” of that. How does it make a library more robust?

I do write libraries myself, and if there is something I am missing, I very much would like to know.

Regards,
Rien.

The usual thing I've run into in practice follows this general pattern:

• A non-threadsafe class is introduced
• Years or decades pass
• Someone (me) tries to make the class threadsafe by adding locking
• In the intervening years, subclasses have been introduced that override methods now called while holding a lock, and reentrantly call back into other methods that take the lock

I've worked around this using recursive mutexes in some cases, but in more extreme cases the subclass synchronously called out to another thread, and that thread reentered the lock.

A defensive rule I've adopted in some new code is "public methods are not allowed to call other public methods", which avoids reentrancy issues, but also makes subclassing somewhat useless since the work is being done by private non-overridable methods.

David

That is imo a good usage of this feature “because it exists”.
However, on my list, it would fall short of making the feature “necessary”.

Like many access level “problems” they don’t really make something possible, they just document what should not be done. And since nobody RTFM (stackoverflow) that may seem like enough to justify something. However it can never replaced knowledge.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: Balancingrock (Rien) · GitHub
Project: http://swiftfire.nl

···

On 16 Feb 2017, at 03:45, David Smith <david_smith@apple.com> wrote:

On Feb 15, 2017, at 8:35 AM, Rien via swift-evolution <swift-evolution@swift.org> wrote:

On 15 Feb 2017, at 17:02, Matthew Johnson <matthew@anandabits.com> wrote:

On Feb 15, 2017, at 9:59 AM, Rien <Rien@Balancingrock.nl> wrote:

On 15 Feb 2017, at 16:45, Matthew Johnson <matthew@anandabits.com> wrote:

On Feb 15, 2017, at 9:35 AM, Rien <Rien@Balancingrock.nl> wrote:

On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution <swift-evolution@swift.org> wrote:

On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

Rien.

There are cases where subclassing does not make sense. And thus preventing subclasses adds information for those users that don’t RTFM. But that imo is not worth the impact extra complexity places on all other users.

Rien.

_______________________________________________
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

DevAndArtist · February 15, 2017, 5:20pm

To summarize everything, I think whenever we get submodules in Swift having a consistent public vs. open behavior would have a great impact when some of us will work on huge (team) projects.

I do not actively support the idea of @closed. I see its benefits, but first I need to get my head around it’s complete behavior (on all different types, on their members). That said I’ll be more quite on that problem. :)

···

--
Adrian Zubarev
Sent with Airmail

Am 15. Februar 2017 um 18:09:52, Adrian Zubarev (adrian.zubarev@devandartist.com) schrieb:

As I already said:

To make that feature happen, we need the protocol to be public (regardless if you can conform to it or not).
Today you can conform to every protocol because in reality they are open today.
If we remove the property requirement from the protocol the client can conform it to any type and break my API by calling the subscript with a wrong type: document["something", NSObject()] (assuming extension NSObject : SubscriptParameterType).
That forces me to create a requirement for the protocol which solves the issue in my cases, however there might exist other issues, which could be far more complicated than mine is.
That also implies I have make the enum public.
Which follows by the fact that I’m creating unnecessary copy operations to wrap every instance that conforms to my protocol into an enum case. From internal API perspective I also have to unwrap the enum case.
Instead if we had consistent public vs. open behavior, I could make the protocol public (but-not-open), remove the requirement from it completely, remove the enum completely and simply cast to Int or String because as the author of the library I would know that the client won’t be able to conform to my protocol.

Importing my library will show the client only this:

extension Int : SubscriptParameterType {}
extension String : SubscriptParameterType {}

--
Adrian Zubarev
Sent with Airmail

Am 15. Februar 2017 um 17:50:41, Rien (rien@balancingrock.nl) schrieb:

On 15 Feb 2017, at 17:22, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

A short example where I personally wanted a public-but-not-open protocol:

public protocol SubscriptParameterType {

// This property was needed to prevent the client from breaking
// the library by conforming to the protocol, but I'd like to
// keep it invisible for the client, or even better prevent the
// client from conforming to the protocol.
var parameter: Document.SubscriptParameter { get }
}

extension Document {

public enum SubscriptParameter {

case string(String)
case integer(Int)
}
}

extension String : SubscriptParameterType {

public var parameter: Document.SubscriptParameter {

return .string(self)
}
}

extension Int : SubscriptParameterType {

public var parameter: Document.SubscriptParameter {

return .integer(self)
}
}

// Somewhere inside the `Document` type
public subscript(firstKey: String, parameters: SubscriptParameterType...) -> Value? { … }

That implementation enables more safe queries of my Document type like document["key1", intIndexInstance, stringKeyInstance, 10, "key"] rather than document["key1/\(intIndexInstance)/\(stringKeyInstance)/10/key”]

I see how that makes queries better.
However what I do not see is how making the protocol “open” would make this less safe.
(I do not see a reason to make it open either, but that is not the question)

It may be obvious to everyone else, but I don’t see it. Am I suffering from a brain freeze?.

Regards,
Rien.

.

--
Adrian Zubarev
Sent with Airmail

Am 15. Februar 2017 um 17:03:32, Matthew Johnson via swift-evolution (swift-evolution@swift.org) schrieb:

On Feb 15, 2017, at 9:59 AM, Rien <Rien@Balancingrock.nl> wrote:

On 15 Feb 2017, at 16:45, Matthew Johnson <matthew@anandabits.com> wrote:

On Feb 15, 2017, at 9:35 AM, Rien <Rien@Balancingrock.nl> wrote:

On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution <swift-evolution@swift.org> wrote:

On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

Our philosophy in general, however, is to default to the behavior which preserves the most flexibility for the library designer.

Actually, I thought the philosophy was to preserver type safety. When did that change?

Also, when was the library designer prioritised ahead of the application developer?

Both open and non-open classes are common, but we chose to give non-open classes the `public` keyword because that's the flexibility-preserving option.

No it isn’t, it’s the flexibility restricting option. The consumer of an open class can subclass it. The consumer of a public class cannot subclass it. How is the second more flexible than the first?

It reduces complexity for the library author by allowing them to opt-out of the complexity involved in supporting unknown, user-defined subclasses. It is important to allow libraries to have this flexibility. They are free to declare a class `open` if they want to allow subclassing. It’s even possibly for a library to declare all classes `open` if it wishes to do so. But *requiring* that would reduce the design space libraries are allowed to explore and / or introduce fragility by moving the subclass restriction to a comment.

Why would a library author want to prohibit subclasses?
A library user can always wrap the class and subclass the wrapper.

This is composition, not inheritance. The most important difference is that a wrapper cannot override methods, it can only wrap and / or forward them. This means that when the superclass calls a method on `self` that method *always* invokes its version of that method rather than a subclass override. This is a very important difference.

Agreed, however that does not answer the question why would a library developer want to disallow subclassing?
I do not see a use case for that. I.e. a feature that cannot be implemented without it. (without “open”)

The feature it enables is more robust libraries and the ability for library authors to better reason about their code. You may not find this benefit enough to be worth a language feature, but many of us do.

Rien.

There are cases where subclassing does not make sense. And thus preventing subclasses adds information for those users that don’t RTFM. But that imo is not worth the impact extra complexity places on all other users.

Rien.

_______________________________________________
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

Rien · February 15, 2017, 6:11pm

As I already said:

  • To make that feature happen, we need the protocol to be public (regardless if you can conform to it or not).
  • Today you can conform to every protocol because in reality they are open today.
  • If we remove the property requirement from the protocol the client can conform it to any type and break my API by calling the subscript with a wrong type: document["something", NSObject()] (assuming extension NSObject : SubscriptParameterType).
  • That forces me to create a requirement for the protocol which solves the issue in my cases, however there might exist other issues, which could be far more complicated than mine is.
  • That also implies I have make the enum public.
  • Which follows by the fact that I’m creating unnecessary copy operations to wrap every instance that conforms to my protocol into an enum case. From internal API perspective I also have to unwrap the enum case.
Instead if we had consistent public vs. open behavior, I could make the protocol public (but-not-open), remove the requirement from it completely, remove the enum completely and simply cast to Int or String because as the author of the library I would know that the client won’t be able to conform to my protocol.

Importing my library will show the client only this:

extension Int : SubscriptParameterType {}
extension String : SubscriptParameterType {}

Ok, thanks, I think I get it now. So you showed the work-around rather than the problem :-)
However you could also implement this by creating two subscript operations, one for integer and one for string.

So while I agree that this might serve as an example on why a non-confirmable protocol might be useful, my original question still stands: how can subclassing create “brittle” libraries?

Also note that adding an extra access level did nothing to prevent brittle libraries… that task is still with the developer.

PS, this is not an educational list, so … :-)

Regards,
Rien.

···

On 15 Feb 2017, at 18:09, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:

--
Adrian Zubarev
Sent with Airmail

Am 15. Februar 2017 um 17:50:41, Rien (rien@balancingrock.nl) schrieb:

> On 15 Feb 2017, at 17:22, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:
>
> A short example where I personally wanted a public-but-not-open protocol:
>
> public protocol SubscriptParameterType {
>
> // This property was needed to prevent the client from breaking
> // the library by conforming to the protocol, but I'd like to
> // keep it invisible for the client, or even better prevent the
> // client from conforming to the protocol.
> var parameter: Document.SubscriptParameter { get }
> }
>
> extension Document {
>
> public enum SubscriptParameter {
>
> case string(String)
> case integer(Int)
> }
> }
>
> extension String : SubscriptParameterType {
>
> public var parameter: Document.SubscriptParameter {
>
> return .string(self)
> }
> }
>
> extension Int : SubscriptParameterType {
>
> public var parameter: Document.SubscriptParameter {
>
> return .integer(self)
> }
> }
>
> // Somewhere inside the `Document` type
> public subscript(firstKey: String, parameters: SubscriptParameterType...) -> Value? { … }
>
> That implementation enables more safe queries of my Document type like document["key1", intIndexInstance, stringKeyInstance, 10, "key"] rather than document["key1/\(intIndexInstance)/\(stringKeyInstance)/10/key”]

I see how that makes queries better.
However what I do not see is how making the protocol “open” would make this less safe.
(I do not see a reason to make it open either, but that is not the question)

It may be obvious to everyone else, but I don’t see it. Am I suffering from a brain freeze?.

Regards,
Rien.

> .
>

>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 15. Februar 2017 um 17:03:32, Matthew Johnson via swift-evolution (swift-evolution@swift.org) schrieb:
>
>>
>>> On Feb 15, 2017, at 9:59 AM, Rien <Rien@Balancingrock.nl> wrote:
>>>
>>>>
>>>> On 15 Feb 2017, at 16:45, Matthew Johnson <matthew@anandabits.com> wrote:
>>>>
>>>>>
>>>>> On Feb 15, 2017, at 9:35 AM, Rien <Rien@Balancingrock.nl> wrote:
>>>>>
>>>>>
>>>>>> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
>>>>>>
>>>>>>
>>>>>>> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution <swift-evolution@swift.org> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Our philosophy in general, however, is to default to the behavior which preserves the most flexibility for the library designer.
>>>>>>>
>>>>>>> Actually, I thought the philosophy was to preserver type safety. When did that change?
>>>>>>>
>>>>>>> Also, when was the library designer prioritised ahead of the application developer?
>>>>>>>
>>>>>>>
>>>>>>>> Both open and non-open classes are common, but we chose to give non-open classes the `public` keyword because that's the flexibility-preserving option.
>>>>>>>
>>>>>>> No it isn’t, it’s the flexibility restricting option. The consumer of an open class can subclass it. The consumer of a public class cannot subclass it. How is the second more flexible than the first?
>>>>>>
>>>>>> It reduces complexity for the library author by allowing them to opt-out of the complexity involved in supporting unknown, user-defined subclasses. It is important to allow libraries to have this flexibility. They are free to declare a class `open` if they want to allow subclassing. It’s even possibly for a library to declare all classes `open` if it wishes to do so. But *requiring* that would reduce the design space libraries are allowed to explore and / or introduce fragility by moving the subclass restriction to a comment.
>>>>>>
>>>>>
>>>>> Why would a library author want to prohibit subclasses?
>>>>> A library user can always wrap the class and subclass the wrapper.
>>>>
>>>> This is composition, not inheritance. The most important difference is that a wrapper cannot override methods, it can only wrap and / or forward them. This means that when the superclass calls a method on `self` that method *always* invokes its version of that method rather than a subclass override. This is a very important difference.
>>>>
>>>
>>> Agreed, however that does not answer the question why would a library developer want to disallow subclassing?
>>> I do not see a use case for that. I.e. a feature that cannot be implemented without it. (without “open”)
>>
>> The feature it enables is more robust libraries and the ability for library authors to better reason about their code. You may not find this benefit enough to be worth a language feature, but many of us do.
>>
>>>
>>> Rien.
>>>
>>>>>
>>>>> There are cases where subclassing does not make sense. And thus preventing subclasses adds information for those users that don’t RTFM. But that imo is not worth the impact extra complexity places on all other users.
>>>>>
>>>>> Rien.
>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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

David_Smith · February 16, 2017, 7:20pm

Our philosophy in general, however, is to default to the behavior which preserves the most flexibility for the library designer.

Actually, I thought the philosophy was to preserver type safety. When did that change?

Also, when was the library designer prioritised ahead of the application developer?

Both open and non-open classes are common, but we chose to give non-open classes the `public` keyword because that's the flexibility-preserving option.

No it isn’t, it’s the flexibility restricting option. The consumer of an open class can subclass it. The consumer of a public class cannot subclass it. How is the second more flexible than the first?

It reduces complexity for the library author by allowing them to opt-out of the complexity involved in supporting unknown, user-defined subclasses. It is important to allow libraries to have this flexibility. They are free to declare a class `open` if they want to allow subclassing. It’s even possibly for a library to declare all classes `open` if it wishes to do so. But *requiring* that would reduce the design space libraries are allowed to explore and / or introduce fragility by moving the subclass restriction to a comment.

Why would a library author want to prohibit subclasses?
A library user can always wrap the class and subclass the wrapper.

This is composition, not inheritance. The most important difference is that a wrapper cannot override methods, it can only wrap and / or forward them. This means that when the superclass calls a method on `self` that method *always* invokes its version of that method rather than a subclass override. This is a very important difference.

Agreed, however that does not answer the question why would a library developer want to disallow subclassing?
I do not see a use case for that. I.e. a feature that cannot be implemented without it. (without “open”)

The feature it enables is more robust libraries and the ability for library authors to better reason about their code. You may not find this benefit enough to be worth a language feature, but many of us do.

You start of with a claim “more robust libraries”.
I would really like to know the “how” of that. How does it make a library more robust?

I do write libraries myself, and if there is something I am missing, I very much would like to know.

Regards,
Rien.

The usual thing I've run into in practice follows this general pattern:

• A non-threadsafe class is introduced
• Years or decades pass
• Someone (me) tries to make the class threadsafe by adding locking
• In the intervening years, subclasses have been introduced that override methods now called while holding a lock, and reentrantly call back into other methods that take the lock

I've worked around this using recursive mutexes in some cases, but in more extreme cases the subclass synchronously called out to another thread, and that thread reentered the lock.

A defensive rule I've adopted in some new code is "public methods are not allowed to call other public methods", which avoids reentrancy issues, but also makes subclassing somewhat useless since the work is being done by private non-overridable methods.

David

That is imo a good usage of this feature “because it exists”.
However, on my list, it would fall short of making the feature “necessary”.

Like many access level “problems” they don’t really make something possible, they just document what should not be done. And since nobody RTFM (stackoverflow) that may seem like enough to justify something. However it can never replaced knowledge.

Regards,
Rien

Site: http://balancingrock.nl <http://balancingrock.nl/>
Blog: http://swiftrien.blogspot.com <http://swiftrien.blogspot.com/>
Github: Balancingrock (Rien) · GitHub
Project: http://swiftfire.nl <Indobet - Tempat Daftar Login Rtp Slot Gacor Indonesia;

Hm. I'm not sure I understand. As far as I know this sort of thing ("a library [in this case one nearly everyone on this list uses constantly] has to be slower and/or less threadsafe because of subclass compatibility requirements") is in fact the motivation for having an open/public distinction at all.

Anyway, I've been mostly staying out of this debate, I just wanted to provide a more concrete example in response to your request for one :)

David

···

On Feb 15, 2017, at 10:57 PM, Rien <Rien@balancingrock.nl> wrote:

On 16 Feb 2017, at 03:45, David Smith <david_smith@apple.com> wrote:

On Feb 15, 2017, at 8:35 AM, Rien via swift-evolution <swift-evolution@swift.org> wrote:

On 15 Feb 2017, at 17:02, Matthew Johnson <matthew@anandabits.com> wrote:

On Feb 15, 2017, at 9:59 AM, Rien <Rien@Balancingrock.nl> wrote:

On 15 Feb 2017, at 16:45, Matthew Johnson <matthew@anandabits.com> wrote:

On Feb 15, 2017, at 9:35 AM, Rien <Rien@Balancingrock.nl> wrote:

On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution <swift-evolution@swift.org> wrote:

On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

Rien.

There are cases where subclassing does not make sense. And thus preventing subclasses adds information for those users that don’t RTFM. But that imo is not worth the impact extra complexity places on all other users.

Rien.

_______________________________________________
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

DevAndArtist · February 15, 2017, 6:27pm

Inline:

···

--
Adrian Zubarev
Sent with Airmail

Am 15. Februar 2017 um 19:11:12, Rien (rien@balancingrock.nl) schrieb:

On 15 Feb 2017, at 18:09, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:

As I already said:

• To make that feature happen, we need the protocol to be public (regardless if you can conform to it or not).
• Today you can conform to every protocol because in reality they are open today.
• If we remove the property requirement from the protocol the client can conform it to any type and break my API by calling the subscript with a wrong type: document["something", NSObject()] (assuming extension NSObject : SubscriptParameterType).
• That forces me to create a requirement for the protocol which solves the issue in my cases, however there might exist other issues, which could be far more complicated than mine is.
• That also implies I have make the enum public.
• Which follows by the fact that I’m creating unnecessary copy operations to wrap every instance that conforms to my protocol into an enum case. From internal API perspective I also have to unwrap the enum case.
Instead if we had consistent public vs. open behavior, I could make the protocol public (but-not-open), remove the requirement from it completely, remove the enum completely and simply cast to Int or String because as the author of the library I would know that the client won’t be able to conform to my protocol.

Importing my library will show the client only this:

extension Int : SubscriptParameterType {}
extension String : SubscriptParameterType {}

Ok, thanks, I think I get it now. So you showed the work-around rather than the problem :-)
However you could also implement this by creating two subscript operations, one for integer and one for string.
No not really, the idea behind this approach is carefully crafted. Plus I do not want optional chaining between subscripts, this is messy `document[“string”]?[10]?[“key”]`.

So while I agree that this might serve as an example on why a non-confirmable protocol might be useful, my original question still stands: how can subclassing create “brittle” libraries?
If one would want the client user only to use subclasses of a certain superclass of the same library for whatever reasons. These subclasses might interact with each other internally (which is not meant to be public by any means). `final public` will not make it happen because then you couldn’t create any of these subclasses at all.

You’re asking here such a general question that simply cannot be answered easily. I also could ask everyone why on earth would be want to hide anything from the client? Lets make everything public, if the client breaks something it’s his fault. <— Clearly not the way to go right? A distinction between `public` and `open` adds more flexibility to solve issues that previously might not had any good solutions.

Also note that adding an extra access level did nothing to prevent brittle libraries… that task is still with the developer.

PS, this is not an educational list, so … :-)
Being sarcastic?

Regards,
Rien.

--
Adrian Zubarev
Sent with Airmail

Am 15. Februar 2017 um 17:50:41, Rien (rien@balancingrock.nl) schrieb:

> On 15 Feb 2017, at 17:22, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:
>
> A short example where I personally wanted a public-but-not-open protocol:
>
> public protocol SubscriptParameterType {
>
> // This property was needed to prevent the client from breaking
> // the library by conforming to the protocol, but I'd like to
> // keep it invisible for the client, or even better prevent the
> // client from conforming to the protocol.
> var parameter: Document.SubscriptParameter { get }
> }
>
> extension Document {
>
> public enum SubscriptParameter {
>
> case string(String)
> case integer(Int)
> }
> }
>
> extension String : SubscriptParameterType {
>
> public var parameter: Document.SubscriptParameter {
>
> return .string(self)
> }
> }
>
> extension Int : SubscriptParameterType {
>
> public var parameter: Document.SubscriptParameter {
>
> return .integer(self)
> }
> }
>
> // Somewhere inside the `Document` type
> public subscript(firstKey: String, parameters: SubscriptParameterType...) -> Value? { … }
>
> That implementation enables more safe queries of my Document type like document["key1", intIndexInstance, stringKeyInstance, 10, "key"] rather than document["key1/\(intIndexInstance)/\(stringKeyInstance)/10/key”]

I see how that makes queries better.
However what I do not see is how making the protocol “open” would make this less safe.
(I do not see a reason to make it open either, but that is not the question)

It may be obvious to everyone else, but I don’t see it. Am I suffering from a brain freeze?.

Regards,
Rien.

> .
>

>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 15. Februar 2017 um 17:03:32, Matthew Johnson via swift-evolution (swift-evolution@swift.org) schrieb:
>
>>
>>> On Feb 15, 2017, at 9:59 AM, Rien <Rien@Balancingrock.nl> wrote:
>>>
>>>>
>>>> On 15 Feb 2017, at 16:45, Matthew Johnson <matthew@anandabits.com> wrote:
>>>>
>>>>>
>>>>> On Feb 15, 2017, at 9:35 AM, Rien <Rien@Balancingrock.nl> wrote:
>>>>>
>>>>>
>>>>>> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
>>>>>>
>>>>>>
>>>>>>> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution <swift-evolution@swift.org> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Our philosophy in general, however, is to default to the behavior which preserves the most flexibility for the library designer.
>>>>>>>
>>>>>>> Actually, I thought the philosophy was to preserver type safety. When did that change?
>>>>>>>
>>>>>>> Also, when was the library designer prioritised ahead of the application developer?
>>>>>>>
>>>>>>>
>>>>>>>> Both open and non-open classes are common, but we chose to give non-open classes the `public` keyword because that's the flexibility-preserving option.
>>>>>>>
>>>>>>> No it isn’t, it’s the flexibility restricting option. The consumer of an open class can subclass it. The consumer of a public class cannot subclass it. How is the second more flexible than the first?
>>>>>>
>>>>>> It reduces complexity for the library author by allowing them to opt-out of the complexity involved in supporting unknown, user-defined subclasses. It is important to allow libraries to have this flexibility. They are free to declare a class `open` if they want to allow subclassing. It’s even possibly for a library to declare all classes `open` if it wishes to do so. But *requiring* that would reduce the design space libraries are allowed to explore and / or introduce fragility by moving the subclass restriction to a comment.
>>>>>>
>>>>>
>>>>> Why would a library author want to prohibit subclasses?
>>>>> A library user can always wrap the class and subclass the wrapper.
>>>>
>>>> This is composition, not inheritance. The most important difference is that a wrapper cannot override methods, it can only wrap and / or forward them. This means that when the superclass calls a method on `self` that method *always* invokes its version of that method rather than a subclass override. This is a very important difference.
>>>>
>>>
>>> Agreed, however that does not answer the question why would a library developer want to disallow subclassing?
>>> I do not see a use case for that. I.e. a feature that cannot be implemented without it. (without “open”)
>>
>> The feature it enables is more robust libraries and the ability for library authors to better reason about their code. You may not find this benefit enough to be worth a language feature, but many of us do.
>>
>>>
>>> Rien.
>>>
>>>>>
>>>>> There are cases where subclassing does not make sense. And thus preventing subclasses adds information for those users that don’t RTFM. But that imo is not worth the impact extra complexity places on all other users.
>>>>>
>>>>> Rien.
>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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

DevAndArtist · February 15, 2017, 6:31pm

If you happen not to bump into these issues yet, then simply call yourself lucky. ;)

···

--
Adrian Zubarev
Sent with Airmail

Am 15. Februar 2017 um 19:27:06, Adrian Zubarev (adrian.zubarev@devandartist.com) schrieb:

Inline:

--
Adrian Zubarev
Sent with Airmail

Am 15. Februar 2017 um 19:11:12, Rien (rien@balancingrock.nl) schrieb:

On 15 Feb 2017, at 18:09, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:

As I already said:

• To make that feature happen, we need the protocol to be public (regardless if you can conform to it or not).
• Today you can conform to every protocol because in reality they are open today.
• If we remove the property requirement from the protocol the client can conform it to any type and break my API by calling the subscript with a wrong type: document["something", NSObject()] (assuming extension NSObject : SubscriptParameterType).
• That forces me to create a requirement for the protocol which solves the issue in my cases, however there might exist other issues, which could be far more complicated than mine is.
• That also implies I have make the enum public.
• Which follows by the fact that I’m creating unnecessary copy operations to wrap every instance that conforms to my protocol into an enum case. From internal API perspective I also have to unwrap the enum case.
Instead if we had consistent public vs. open behavior, I could make the protocol public (but-not-open), remove the requirement from it completely, remove the enum completely and simply cast to Int or String because as the author of the library I would know that the client won’t be able to conform to my protocol.

Importing my library will show the client only this:

extension Int : SubscriptParameterType {}
extension String : SubscriptParameterType {}

Ok, thanks, I think I get it now. So you showed the work-around rather than the problem :-)
However you could also implement this by creating two subscript operations, one for integer and one for string.
No not really, the idea behind this approach is carefully crafted. Plus I do not want optional chaining between subscripts, this is messy `document[“string”]?[10]?[“key”]`.

So while I agree that this might serve as an example on why a non-confirmable protocol might be useful, my original question still stands: how can subclassing create “brittle” libraries?
If one would want the client user only to use subclasses of a certain superclass of the same library for whatever reasons. These subclasses might interact with each other internally (which is not meant to be public by any means). `final public` will not make it happen because then you couldn’t create any of these subclasses at all.

You’re asking here such a general question that simply cannot be answered easily. I also could ask everyone why on earth would be want to hide anything from the client? Lets make everything public, if the client breaks something it’s his fault. <— Clearly not the way to go right? A distinction between `public` and `open` adds more flexibility to solve issues that previously might not had any good solutions.

Also note that adding an extra access level did nothing to prevent brittle libraries… that task is still with the developer.

PS, this is not an educational list, so … :-)
Being sarcastic?

Regards,
Rien.

--
Adrian Zubarev
Sent with Airmail

Am 15. Februar 2017 um 17:50:41, Rien (rien@balancingrock.nl) schrieb:

> On 15 Feb 2017, at 17:22, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:
>
> A short example where I personally wanted a public-but-not-open protocol:
>
> public protocol SubscriptParameterType {
>
> // This property was needed to prevent the client from breaking
> // the library by conforming to the protocol, but I'd like to
> // keep it invisible for the client, or even better prevent the
> // client from conforming to the protocol.
> var parameter: Document.SubscriptParameter { get }
> }
>
> extension Document {
>
> public enum SubscriptParameter {
>
> case string(String)
> case integer(Int)
> }
> }
>
> extension String : SubscriptParameterType {
>
> public var parameter: Document.SubscriptParameter {
>
> return .string(self)
> }
> }
>
> extension Int : SubscriptParameterType {
>
> public var parameter: Document.SubscriptParameter {
>
> return .integer(self)
> }
> }
>
> // Somewhere inside the `Document` type
> public subscript(firstKey: String, parameters: SubscriptParameterType...) -> Value? { … }
>
> That implementation enables more safe queries of my Document type like document["key1", intIndexInstance, stringKeyInstance, 10, "key"] rather than document["key1/\(intIndexInstance)/\(stringKeyInstance)/10/key”]

I see how that makes queries better.
However what I do not see is how making the protocol “open” would make this less safe.
(I do not see a reason to make it open either, but that is not the question)

It may be obvious to everyone else, but I don’t see it. Am I suffering from a brain freeze?.

Regards,
Rien.

> .
>

>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 15. Februar 2017 um 17:03:32, Matthew Johnson via swift-evolution (swift-evolution@swift.org) schrieb:
>
>>
>>> On Feb 15, 2017, at 9:59 AM, Rien <Rien@Balancingrock.nl> wrote:
>>>
>>>>
>>>> On 15 Feb 2017, at 16:45, Matthew Johnson <matthew@anandabits.com> wrote:
>>>>
>>>>>
>>>>> On Feb 15, 2017, at 9:35 AM, Rien <Rien@Balancingrock.nl> wrote:
>>>>>
>>>>>
>>>>>> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
>>>>>>
>>>>>>
>>>>>>> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution <swift-evolution@swift.org> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Our philosophy in general, however, is to default to the behavior which preserves the most flexibility for the library designer.
>>>>>>>
>>>>>>> Actually, I thought the philosophy was to preserver type safety. When did that change?
>>>>>>>
>>>>>>> Also, when was the library designer prioritised ahead of the application developer?
>>>>>>>
>>>>>>>
>>>>>>>> Both open and non-open classes are common, but we chose to give non-open classes the `public` keyword because that's the flexibility-preserving option.
>>>>>>>
>>>>>>> No it isn’t, it’s the flexibility restricting option. The consumer of an open class can subclass it. The consumer of a public class cannot subclass it. How is the second more flexible than the first?
>>>>>>
>>>>>> It reduces complexity for the library author by allowing them to opt-out of the complexity involved in supporting unknown, user-defined subclasses. It is important to allow libraries to have this flexibility. They are free to declare a class `open` if they want to allow subclassing. It’s even possibly for a library to declare all classes `open` if it wishes to do so. But *requiring* that would reduce the design space libraries are allowed to explore and / or introduce fragility by moving the subclass restriction to a comment.
>>>>>>
>>>>>
>>>>> Why would a library author want to prohibit subclasses?
>>>>> A library user can always wrap the class and subclass the wrapper.
>>>>
>>>> This is composition, not inheritance. The most important difference is that a wrapper cannot override methods, it can only wrap and / or forward them. This means that when the superclass calls a method on `self` that method *always* invokes its version of that method rather than a subclass override. This is a very important difference.
>>>>
>>>
>>> Agreed, however that does not answer the question why would a library developer want to disallow subclassing?
>>> I do not see a use case for that. I.e. a feature that cannot be implemented without it. (without “open”)
>>
>> The feature it enables is more robust libraries and the ability for library authors to better reason about their code. You may not find this benefit enough to be worth a language feature, but many of us do.
>>
>>>
>>> Rien.
>>>
>>>>>
>>>>> There are cases where subclassing does not make sense. And thus preventing subclasses adds information for those users that don’t RTFM. But that imo is not worth the impact extra complexity places on all other users.
>>>>>
>>>>> Rien.
>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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

Rien · February 15, 2017, 6:57pm

Inline:

--
Adrian Zubarev
Sent with Airmail

Am 15. Februar 2017 um 19:11:12, Rien (rien@balancingrock.nl) schrieb:

>
> As I already said:
>
> • To make that feature happen, we need the protocol to be public (regardless if you can conform to it or not).
> • Today you can conform to every protocol because in reality they are open today.
> • If we remove the property requirement from the protocol the client can conform it to any type and break my API by calling the subscript with a wrong type: document["something", NSObject()] (assuming extension NSObject : SubscriptParameterType).
> • That forces me to create a requirement for the protocol which solves the issue in my cases, however there might exist other issues, which could be far more complicated than mine is.
> • That also implies I have make the enum public.
> • Which follows by the fact that I’m creating unnecessary copy operations to wrap every instance that conforms to my protocol into an enum case. From internal API perspective I also have to unwrap the enum case.
> Instead if we had consistent public vs. open behavior, I could make the protocol public (but-not-open), remove the requirement from it completely, remove the enum completely and simply cast to Int or String because as the author of the library I would know that the client won’t be able to conform to my protocol.
>
> Importing my library will show the client only this:
>
> extension Int : SubscriptParameterType {}
> extension String : SubscriptParameterType {}
>
>

Ok, thanks, I think I get it now. So you showed the work-around rather than the problem :-)
However you could also implement this by creating two subscript operations, one for integer and one for string.

No not really, the idea behind this approach is carefully crafted. Plus I do not want optional chaining between subscripts, this is messy `document[“string”]?[10]?[“key”]`.

Yes, but there are always more ways to skin a cat :-)
In my SwifterJSON I do use both an int and a string subscript and have solved the optional chaining (rather ugly… but it works).
Also, I overloaded the pipe (“|”) operator that allows me to do away with the array notation like this: … = json | ”books” | 3 | “title"

So while I agree that this might serve as an example on why a non-confirmable protocol might be useful, my original question still stands: how can subclassing create “brittle” libraries?

If one would want the client user only to use subclasses of a certain superclass of the same library for whatever reasons. These subclasses might interact with each other internally (which is not meant to be public by any means). `final public` will not make it happen because then you couldn’t create any of these subclasses at all.

You’re asking here such a general question that simply cannot be answered easily. I also could ask everyone why on earth would be want to hide anything from the client? Lets make everything public, if the client breaks something it’s his fault. <— Clearly not the way to go right? A distinction between `public` and `open` adds more flexibility to solve issues that previously might not had any good solutions.

It does, I am not doubting that at all.
But there are always costs, adding an extra keyword and an extra access layer adds complexity, adds possibilities for errors, leads to more testing, increases cognitive load, steepens the learning curve etc etc. And it does so for ALL swift users. Possibly far outweighing the benefits that accrue to (maybe) just a few developers.

(Like the infamous tax problem: people won’t spend much effort to change the tax system and pay $1 a year less in taxes, but the one organisation/person receiving all those dollars has a huge incentive and will spend -if necessary- all his time to keep the system as is)

Also note that adding an extra access level did nothing to prevent brittle libraries… that task is still with the developer.

PS, this is not an educational list, so … :-)

Being sarcastic?

No, not really. I just wanted to draw attention to the fact that there is no obligation whatsoever to teach me.
So thank you for taking the time!

In your debt,
Rien.

···

On 15 Feb 2017, at 19:27, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:

> On 15 Feb 2017, at 18:09, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:

Regards,
Rien.

>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 15. Februar 2017 um 17:50:41, Rien (rien@balancingrock.nl) schrieb:
>
>>
>> > On 15 Feb 2017, at 17:22, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:
>> >
>> > A short example where I personally wanted a public-but-not-open protocol:
>> >
>> > public protocol SubscriptParameterType {
>> >
>> > // This property was needed to prevent the client from breaking
>> > // the library by conforming to the protocol, but I'd like to
>> > // keep it invisible for the client, or even better prevent the
>> > // client from conforming to the protocol.
>> > var parameter: Document.SubscriptParameter { get }
>> > }
>> >
>> > extension Document {
>> >
>> > public enum SubscriptParameter {
>> >
>> > case string(String)
>> > case integer(Int)
>> > }
>> > }
>> >
>> > extension String : SubscriptParameterType {
>> >
>> > public var parameter: Document.SubscriptParameter {
>> >
>> > return .string(self)
>> > }
>> > }
>> >
>> > extension Int : SubscriptParameterType {
>> >
>> > public var parameter: Document.SubscriptParameter {
>> >
>> > return .integer(self)
>> > }
>> > }
>> >
>> > // Somewhere inside the `Document` type
>> > public subscript(firstKey: String, parameters: SubscriptParameterType...) -> Value? { … }
>> >
>> > That implementation enables more safe queries of my Document type like document["key1", intIndexInstance, stringKeyInstance, 10, "key"] rather than document["key1/\(intIndexInstance)/\(stringKeyInstance)/10/key”]
>>
>> I see how that makes queries better.
>> However what I do not see is how making the protocol “open” would make this less safe.
>> (I do not see a reason to make it open either, but that is not the question)
>>
>> It may be obvious to everyone else, but I don’t see it. Am I suffering from a brain freeze?.
>>
>> Regards,
>> Rien.
>>
>>
>> > .
>> >
>>
>> >
>> >
>> >
>> > --
>> > Adrian Zubarev
>> > Sent with Airmail
>> >
>> > Am 15. Februar 2017 um 17:03:32, Matthew Johnson via swift-evolution (swift-evolution@swift.org) schrieb:
>> >
>> >>
>> >>> On Feb 15, 2017, at 9:59 AM, Rien <Rien@Balancingrock.nl> wrote:
>> >>>
>> >>>>
>> >>>> On 15 Feb 2017, at 16:45, Matthew Johnson <matthew@anandabits.com> wrote:
>> >>>>
>> >>>>>
>> >>>>> On Feb 15, 2017, at 9:35 AM, Rien <Rien@Balancingrock.nl> wrote:
>> >>>>>
>> >>>>>
>> >>>>>> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>>> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution <swift-evolution@swift.org> wrote:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> Our philosophy in general, however, is to default to the behavior which preserves the most flexibility for the library designer.
>> >>>>>>>
>> >>>>>>> Actually, I thought the philosophy was to preserver type safety. When did that change?
>> >>>>>>>
>> >>>>>>> Also, when was the library designer prioritised ahead of the application developer?
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> Both open and non-open classes are common, but we chose to give non-open classes the `public` keyword because that's the flexibility-preserving option.
>> >>>>>>>
>> >>>>>>> No it isn’t, it’s the flexibility restricting option. The consumer of an open class can subclass it. The consumer of a public class cannot subclass it. How is the second more flexible than the first?
>> >>>>>>
>> >>>>>> It reduces complexity for the library author by allowing them to opt-out of the complexity involved in supporting unknown, user-defined subclasses. It is important to allow libraries to have this flexibility. They are free to declare a class `open` if they want to allow subclassing. It’s even possibly for a library to declare all classes `open` if it wishes to do so. But *requiring* that would reduce the design space libraries are allowed to explore and / or introduce fragility by moving the subclass restriction to a comment.
>> >>>>>>
>> >>>>>
>> >>>>> Why would a library author want to prohibit subclasses?
>> >>>>> A library user can always wrap the class and subclass the wrapper.
>> >>>>
>> >>>> This is composition, not inheritance. The most important difference is that a wrapper cannot override methods, it can only wrap and / or forward them. This means that when the superclass calls a method on `self` that method *always* invokes its version of that method rather than a subclass override. This is a very important difference.
>> >>>>
>> >>>
>> >>> Agreed, however that does not answer the question why would a library developer want to disallow subclassing?
>> >>> I do not see a use case for that. I.e. a feature that cannot be implemented without it. (without “open”)
>> >>
>> >> The feature it enables is more robust libraries and the ability for library authors to better reason about their code. You may not find this benefit enough to be worth a language feature, but many of us do.
>> >>
>> >>>
>> >>> Rien.
>> >>>
>> >>>>>
>> >>>>> There are cases where subclassing does not make sense. And thus preventing subclasses adds information for those users that don’t RTFM. But that imo is not worth the impact extra complexity places on all other users.
>> >>>>>
>> >>>>> Rien.
>> >>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> 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
>>