[swift-evolution] Final by default for classes and methods
matthew at anandabits.com
Thu Dec 17 21:15:06 CST 2015
> On Dec 17, 2015, at 8:48 PM, Rod Brown <rodney.brown6 at icloud.com> wrote:
> I completely agree. We have the final keyword for that, ensuring that if I do not plan for it to be subclassable, it cannot be.
> The question here is not “should a framework author be able to block a developer from subclassing?” but “Should I assume it is, or is not, subclassable?"
> I err on the side of flexibility. Others err on the side of simplicity and safety.
Fair enough. I used to err on the side of flexibility as well. For a while Ruby was my favorite language partly because it is extraordinarily flexible.
These days really I appreciate having a compiler prove as much as it possibly can about my code. Every time the compiler proves something for me there is one more thing I know with absolute certainty about it (modulo compiler bugs!) and one less thing I need to think carefully about on my own.
The ability to make assumptions about code because the compiler proved them to be true is extremely liberating! Far more liberating than flexibility that was not designed with intention.
>> On 18 Dec 2015, at 1:30 PM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>> Legitimacy is in the eye of the beholder. I think it is quite legitimate for a framework author (especially the platform vendor) to decide what you can and cannot do with their framework.
>> When I hear about code in Apple’s frameworks that is responsible detecting and working around inappropriate uses of their frameworks it makes me cringe. Anything that helps to remove the need for this in the long run is a really great thing.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution