> On 12 Dec 2016, at 07:23, Benjamin Spratling via swift-evolution > <swift-evolution@swift.org> wrote: > > > > -Ben > > Sent from my iPhone. > >> On Dec 11, 2016, at 11:43 PM, Brian Gesiak <modoca...@gmail.com> 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,
That is a very elusive goal. The best way to do this is through hiring competent people… One of the quotes I like in this regard: a monkey with a tool is still a monkey… But I know, we all have to work with the hand we are dealt with. Nevertheless it is easy to sink a lot of work in this subject with little to show for it. People will make mistakes, no matter how good the tool. I have often felt that we need a certain balance, i.e. the tool should hurt you when making a mistake, but then it should not hurt so much that you die. That spurs good practises by the programmer who otherwise might become complacent. I know I get complacent with some Swift/Xcode features… and I hate it when I do, but I still do it… Btw I have a lot of Ada experience. I love that language. It does way more in enforcing a proper design and catching programmers misttakes. However it never has gotten much traction for general applications. I blame that on the invisibility of avoided error’s… Just rambling, no real point here… well, maybe one: don’t aim for perfection, but make sure it hurts when perfection is not achieved. That way we will get paid for experience… :-o) Rien. > 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 > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
