-Ben
Sent from my iPhone. > On Dec 11, 2016, at 11:43 PM, Brian Gesiak <[email protected]> wrote: > Maybe your goal is to ensure that other programmers don't accidentally change > the accessibility levels. Again, I think because they're straightforward, I > don't think there's much danger there. > > To me, tests for accessibility would be redundant. It would be like adding a > test to verify that my struct 'Foo' has a member named 'bar'. If I ever > decided to rename 'Foo.bar', I would have to update the test. But I would > never "accidentally" rename 'Foo.bar' -- if I changed the name, it's because > I modified the code for that purpose. A test adds overhead, but no benefit. > > I feel the same about the 'mutating', 'weak', 'unowned', and 'final'. > > It's definitely subjective, though. You might feel that the tests I describe > above are valuable, and you're entitled to that opinion. I have been in some situations recently in which encapsulation was untestable, and on a team with >10 developers and no automated test to catch that change, there were issues. In the end we shipped knowing there was a bug, because 15 weeks of work had been based on it, and it would have required a redesign to fix. If I need a test that there is a property named 'bar', I can write a test which accesses the member, and even specify a required type and explicitly test whether the property does or does not conform to the protocol. Even if it's private, I can use a Mirror to extract its value. My motivation is: I got tired of hearing "if you did it right, it would have worked", which I now view as an excuse for lack of good design (in most cases). For the past several months, I have been investigating design patterns which prevent developers from making common mistakes, and how to write tests to catch changes to those patterns. I can't even count the number of unfathomable bugs I've fixed merely by improving the design. Swift is notable in that its compiler can enforce many of these patterns, so I prefer it over Obj-C. Proper encapsulation is one such technique, and it turns out it's untestable. Thanks for your suggestion about researching how other languages do this. I'll see what I can do, though the only experience I have in any of the ones you mentioned is pre-11 C++, so if anyone else knows how such checks are done, I'd greatly appreciate hearing from you. -Ben _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
