[swift-evolution] [Proposal] Sealed classes by default
laurent.mihalkovic at gmail.com
Tue Jun 28 08:09:09 CDT 2016
> On Jun 28, 2016, at 1:57 PM, Alejandro Martinez via swift-evolution <swift-evolution at 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.
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 at swift.org> wrote:
>> Does `sealed` allow for any optimizations? Maybe somehow devirtualizing
>> method calls?
>> swift-evolution mailing list
>> swift-evolution at swift.org
> Alejandro Martinez
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution