> On Feb 23, 2017, at 1:34 PM, Joanna Carter <joa...@carterconsulting.org.uk> > wrote: > > >> Le 23 févr. 2017 à 14:59, Matthew Johnson <matt...@anandabits.com> 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.
Sometimes APIs are used internally in production while eventually planned for public visibility. New features in Apple’s frameworks often start life this way. > >> 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? I don’t have a strong feeling about this particular capability. I’m just trying to state the rationale as I understand it. > > -- > Joanna Carter > Carter Consulting > _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
