> On Jun 28, 2016, at 2:31 PM, John McCall via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>> On Jun 28, 2016, at 12:39 PM, Michael Peternell via swift-evolution
>> <swift-evolution@swift.org> wrote:
>> Sealing classes by default is a terrible idea IMHO. Fortunately, my faith in
>> the Swift core team is strong enough so that I cannot believe that this has
>> a chance of ever being implemented at all :)
>>
>> Why do I think it's terrible? I do subclass classes even when they say that
>> you shouldn't do it. I even monkey-patched a few classes in the past. Why?
>> Not because I prefer hacking over clean coding, but to get the job done.
>> Every few months or so I encounter a situation where such hacking attempts
>> are the only feasible way to make something work. Or I use them during
>> research activities or unofficial "feasibility studies". (If that's not the
>> case for you, then maybe you are working in a different job than I. Monkey
>> patching is rarely necessary if you make iPhone apps.) These are situations
>> where everyone else just says "that's not possible". Yes, you can make that
>> USB driver class stop spamming the console; yes, you can stop that library
>> from crashing randomly.
>>
>> There is so much more to say on this topic. Sealing classes is also bad
>> because it prevents forms of experimental coding. It doesn't solve a real
>> problem. How often have I seen bugs where someone subclassed a class that
>> shouldn't be subclassed? That's so rare. But if all classes are sealed by
>> default this will lead to far worse problems. When a developer subclasses a
>> class, he usually has a reason. There already is a `final` keyword in Swift,
>> and a dev really thinks that a class shouldn't be subclass-able, he can use
>> it already. And if I subclass it from Objective-C anyways, then maybe I know
>> what I'm doing?
>>
>> And I'm not buying this "performance" argument. If you want better
>> performance, write the hot functions in C or maybe even in assembler. The
>> dynamic dispatch overhead is not the feature that makes programs bad or
>> slow. It's quadratic algorithms (e.g. unnecessary nested loops), calling
>> functions multiple times (e.g. if(a.foo.bar(x[2]) == "joo" ||
>> a.foo.bar(x[2]) == "fooo" || a.foo.bar(x[2]) == nil) { ... }), or just
>> overly complex code: all of them have more impact than dynamic dispatch.
>> Even worse for performance is unnecessary IO or using graphics APIs
>> inefficiently. A good profiler can help a lot with these issues.
>>
>> Swift should be designed for the real world, not for an ideal world that
>> does not exist and that will never exist.
>
> The design intent of much of Swift is to allow "free" coding within a
> module/file/type while encouraging programmers to think more carefully about
> their public interfaces. Module interfaces are the most serious and
> permanent of these interfaces. It's in keeping with that for declarations to
> make only minimal public guarantees and require the programmer to be more
> explicit about the things they want to allow.
>
> Your arguments about patchability and performance could be applied to every
> feature in the language. They are essentially arguments for a fully-dynamic
> environment.
see https://en.wikipedia.org/wiki/Straw_man
Most OO languages do not seal seal modules (or the equivalent) by default.
Forcing developers to add “final” does not seem onerous. If authors do not have
time to audit their frameworks, the language should not pretend do it for them.
> There's no reason to single out subclassing; for everything you can imagine,
> one programmer's caution will be another's paternalism. You're just making
> the argument here because you're used to a particular way of patching
> Objective-C code, one which will work regardless of this language decision;
That seems personal.
> but most of the old ObjC techniques (e.g. accessing ivars reflectively)
> already won't work on Swift code without unsafe operations, and subclassing
> is a very tiny part of that problem.
>
> And no, we do not and will not accept that performance-sensitive code can
> only possibly be written in C or assembly, or that algorithmic performance is
> the only thing worth worrying about, even for the language implementation.
Could many of the performance advantages of sealing could be gained through
“whole application” optimization?T he benefits could far exceed what is
possible with whole module optimization. It would probably be extremely
difficult and hard to scale, but for packaged, signed applications, it should
be possible some day.
>
> John.
>
>
>
>> -Michael
>>
>>> Am 28.06.2016 um 15:09 schrieb L. Mihalkovic via swift-evolution
>>> <swift-evolution@swift.org>:
>>>
>>>
>>> Regards
>>> LM
>>> (From mobile)
>>>> On Jun 28, 2016, at 1:57 PM, Alejandro Martinez via swift-evolution
>>>> <swift-evolution@swift.org> wrote:
>>>>
>>>> Anton Zhilin: That is one of the points if I’m not mistaken. Sealed
>>>> means that with whole-module-optimization the compiler can optimise
>>>> more things as it can treat it as final for other modules.
>>>>
>>>> L. Mihalkovic: Could you give an example of what exactly do you mean?
>>>> I know one of the reasons behind the proposal is to actually improve
>>>> those situations by forcing us to think more on customisation when
>>>> designing APIs.
>>>
>>> In many situation it has been my experience that libraries can be extended
>>> DESPITE their authors, rather than only thanks to the skills the authors
>>> have shown in planning for the future. It is what happened to me with
>>> AlamoFire, where i was able to extend it because some cracks existed which
>>> let me do something the designers did not think about (to me it was a lack
>>> of imagination to not have anticipated what i wanted to do).
>>>
>>> So if this can happen with a lib made by very experienced/talented
>>> developers, then imagine what happens with far less skilled developers.. it
>>> will mean having to copy code in order extend. It may sound pessimistic,
>>> but if u had seen as much bad code as i have seen, you might understand the
>>> view i am sharing.
>>>
>>> What's worse is that objc is not particularly conducive to good software
>>> architecture (it is a bit like perl and javascript where anything can be
>>> touched from anywhere, and has a limited set of constructs compared to c++,
>>> scala, java, c#, swift). So i do not believe that it has prepared objc devs
>>> to suddenly become great code designers with a language that has multiples
>>> levels of scoping/nesting (i would not use most of the swift libs i have
>>> seen on github to teach software design).
>>>
>>> Hence my conclusion that defaulting to sealed may be giving too much credit
>>> to the code that is currently available for reuse.
>>>
>>>
>>>>
>>>> On Tue, Jun 28, 2016 at 12:44 PM, Anton Zhilin via swift-evolution
>>>> <swift-evolution@swift.org> wrote:
>>>>> Does `sealed` allow for any optimizations? Maybe somehow devirtualizing
>>>>> method calls?
>>>>>
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution@swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>>
>>>>
>>>> --
>>>> Alejandro Martinez
>>>> http://alejandromp.com
>>>> _______________________________________________
>>>> 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 <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
