> Am 11.07.2016 um 03:45 schrieb Rod Brown <[email protected]>: > > That said, I actually think you have a good point however that “sealed” > should be able to be overridden, either in a patch capacity or an “unsafe” > capacity. Should this become final at a later point, you have acknowledged > you know this will be unsafe and are willing to take this risk to get the job > done. This is opt-in risk. > > Perhaps however this shouldn’t be “sealed” declaratively. Perhaps we just > have a keyword for “Open” as an access level, and if you subclass or override > things that are not “open” from other modules, you must mark unsafe. > > I think this is a decent compromise: We allow potential to patch, but > discourage without acknowledgement of the risk. Allow Final and Open to be > declarative. Finally: Someone from the other party who not only speaks about compromise, but also shares a compatible way of thinking :-) All those strict rules are a pointless attempt to trade freedom for security, and are purely cosmetic in most cases: In the context of open source, they are a blunt sword, whose only power is to annoy users. Instead of trying to avoid all possible problems users of your library may run into, it's better to treat them as adults who know what they are doing — and make sure that the actually know what they are doing.
The defaults should match reality, and that is neither "overriding is trouble" nor "it's safe to subclass"; it is "I haven't thought about overriding yet". There is even a natural choice for the syntax to acknowledge that you are aware of doing something that might be dangerous: Simply add an exclamation mark to override. Tino
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
