> On Feb 15, 2017, at 10:57 PM, Rien <[email protected]> wrote:
>
>
>
>> On 16 Feb 2017, at 03:45, David Smith <[email protected]> wrote:
>>
>>>
>>> On Feb 15, 2017, at 8:35 AM, Rien via swift-evolution
>>> <[email protected]> wrote:
>>>
>>>>
>>>> On 15 Feb 2017, at 17:02, Matthew Johnson <[email protected]> wrote:
>>>>
>>>>>
>>>>> On Feb 15, 2017, at 9:59 AM, Rien <[email protected]> wrote:
>>>>>
>>>>>>
>>>>>> On 15 Feb 2017, at 16:45, Matthew Johnson <[email protected]> wrote:
>>>>>>
>>>>>>>
>>>>>>> On Feb 15, 2017, at 9:35 AM, Rien <[email protected]> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution
>>>>>>>> <[email protected]> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution
>>>>>>>>> <[email protected]> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution
>>>>>>>>>> <[email protected]> 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.
>>>
>>> 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: http://github.com/Balancingrock <http://github.com/Balancingrock>
> Project: http://swiftfire.nl <http://swiftfire.nl/>
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
>
>
>>
>>>
>>>>
>>>>>
>>>>> 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
>>>>>>>>> [email protected]
>>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> swift-evolution mailing list
>>>>>>>> [email protected]
>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected]
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
