[swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Goffredo Marocchi]

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 at 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 at swift.org> wrote:
>> 
>> 
>> 
>>> On 07 Dec 2017, at 17:02, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>> 
>>> 
>>>> On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution <swift-evolution at 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171207/98754a64/attachment.html>