Well, mocking was effective and super easy to do proper unit testing with... that must count as a disaster or something ;).
Sent from my iPhone > On 7 Dec 2017, at 15:32, C. Keith Ray via swift-evolution > <swift-evolution@swift.org> wrote: > > Let's see what disasters were created by people abusing NSProxy, the ObjC > moral equivalent of a dynamic member lookup type. > > I'm not aware of anything. > > -- > C. Keith Ray > > * https://leanpub.com/wepntk <- buy my book? > * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf > * http://agilesolutionspace.blogspot.com/ > >> On Dec 7, 2017, at 7:15 AM, Letanyan Arumugam via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >> >>> On 07 Dec 2017, at 17:02, Xiaodi Wu <xiaodi...@gmail.com> wrote: >>> >>> >>>> On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution >>>> <swift-evolution@swift.org> wrote: >>>> >>>>> This seems marginally tolerable, but excessive. >>>>> >>>>> Do we mark every usage of a type that can generate precondition failures >>>>> or fatal errors for reasons other than “no such method?” No, we don’t. >>>>> >>>> >>>> fatalError shouldn’t be used excessively. API surface areas for these >>>> types are going to be massive (infinite technically). I assume many people >>>> are going to be writing a lot of code would these types and calling many >>>> methods and properties which would all essentially have a fatalError. >>>> Would you consider it good code if the majority of all your types had >>>> methods defined with fatalError calls. >>> >>> What is the basis for this claim? Probably the majority of standard library >>> methods check preconditions and trap on failure. That is how I write my >>> code as well. >>>> >> >> I’m talking specifically about fatalError not precondition. fatalError is >> something that goes out with production code while precondition is used for >> debugging. I think you would agree a shipped program that has many states of >> being unrecoverable is not a good design? >> _______________________________________________ >> 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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
