[swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[L. Mihalkovic]

Regards
(From mobile)

> On Jul 19, 2016, at 8:19 PM, Goffredo Marocchi via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> Sent from my iPhone
> 
>> <off-topic>
>> Cocoa currently hides the boilerplate for all of these wonderful constructs behind amazingly effective runtime acrobatics. This fits perfectly into Objective-C, and it also works very well in Swift. But such features could be in better harmony with Swift's unique set of language constructs if their boilerplate was hidden behind amazingly effective **compile-time** acrobatics instead.
>> 
>> Such compile-time acrobatics are hard to perform today, and it is possible that the ability to create such systems will forever remain an advanced skill, just like forging runtime magic requires advanced skills in Objective-C.
> 
> ... rantish...
> 
> I am still not convinced that even the best compiler can fully replace what a powerful runtime can provide no matter the acrobatics you put in in terms of compiler introduced utility code/constructs or the code analysis efforts you can put in at compile time

That is a fact back by some interesting papers. By it is also true that one cannot always be used in place of the other.

> ... unless that work essentially replaces the runtime. Do we want to help coders with a great compiler and static analysis tools? Yes! Do we need to castrate the runtime to achieve this making it physically impossible for developers to escape the controlled environment we strictly want them to live in? I do not think so and we may regret the results once everything including UI and app frameworks are all Swifty™ (it is starting to get marketing firm icky when a discussion is stopped when this word is invoked or inflamed by a disagreement on who is more swiftly orthodox). I think that without holding technology back due to fear, we should not proceed only with the assumption that old way == worst thing ever  while  new way == it is new and young, it must be good.
> 
> Objective-C did not survive and thrive in Cocoa for so many years completely in spite of its many many deficiencies as sometimes it seems on this list (Objective-C being put down more than necessary IMHO... Swift does not need this kind of sometimes slightly biased comparison to be appreciated in full, but it can stand on its own merits). 
> 
> Maybe the reason we like Cocoa/Cocoa Touck/AppKit/UIKit/etc... is precisely because of the beautiful balance it strikes between (sometimes leaning more on developers opting-in) safety and versatility allowing good code to be produced and tested quickly thus allowing easier prototyping, refactoring, and iterative development.
> 
> Sorry for the even more off topic bit and thank you to those people who read this.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160719/b94de216/attachment.html>