> Le 23 févr. 2017 à 14:59, Matthew Johnson <[email protected]> a écrit : > > The rationale for this is that it allows you to explore the eventual design > of a type without exposing it. When you are confident in the design all you > need to does modify the access modifier of the type itself. Without this > capability people might resort to comments indicating the intended future > visibility and then have to remember to go back and convert all of those > comments into the new access modifier when you’re ready to publish the type.
I suppose I can understand that but... Certainly you can check that everything compiles but how does it help if you want to test the code does what you expect? What about testing the validity of inheritance controls? Personally, I test new ideas in a "side" project before integrating into the main project. That say, I get to develop everything at the correct visibilities and with everything ready to just copy and paste to the main project. > The important thing to keep in mind is that software isn’t a fixed, static > thing. It evolves over time. This is a tool to help grow software over time. After over 25 years of developing software and teaching others, I have never heard of such a justification of such a mish-mash of visibilities. This might seem like a good idea for testing but, what about the effect of it on real development where inexperienced developers keep on finding that visibilities that are "possible" don't actually work? -- Joanna Carter Carter Consulting _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
