<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><div style="direction: inherit;"><br></div><br>Sent from my iPhone</div><div><br>On 19 Jul 2016, at 21:41, David Owens II <<a href="mailto:david@owensd.io">david@owensd.io</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 19, 2016, at 11:37 AM, L. Mihalkovic via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><br class=""><br class=""><div class="">Regards</div>(From<span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); "> mobile)</span></div><div class=""><br class="">On Jul 19, 2016, at 8:19 PM, Goffredo Marocchi via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div class=""><div style="direction: inherit;" class=""><br class=""></div>Sent from my iPhone</div><div style="direction: inherit;" class=""><br class=""></div><blockquote type="cite" class=""><div class=""><span class=""></span><span class=""><off-topic></span><br class=""><span class="">Cocoa currently hides the boilerplate for all of these wonderful constructs behind amazingly effective runtime acrobatics. This fits perfectly into Objective-C, and it also works very well in Swift. But such features could be in better harmony with Swift's unique set of language constructs if their boilerplate was hidden behind amazingly effective **compile-time** acrobatics instead.</span><br class=""><span class=""></span><br class=""><span class="">Such compile-time acrobatics are hard to perform today, and it is possible that the ability to create such systems will forever remain an advanced skill, just like forging runtime magic requires advanced skills in Objective-C.</span><br class=""></div></blockquote><div style="direction: inherit;" class=""><br class=""></div><div style="direction: inherit;" class="">... rantish...</div><div style="direction: inherit;" class=""><br class=""></div><div style="direction: inherit;" class="">I am still not convinced that even the best compiler can fully replace what a powerful runtime can provide no matter the acrobatics you put in in terms of compiler introduced utility code/constructs or the code analysis efforts you can put in at compile time</div></div></blockquote><div class=""><br class=""></div><div class="">That is a fact back by some interesting papers. By it is also true that one cannot always be used in place of the other.</div></div></div></blockquote></div><br class=""><div class="">While it is true that the compiler cannot fully replace everything, it can help with many types of errors that are hard to catch at runtime.</div><div class=""><br class=""></div><div class="">I’ll reiterate this again: this proposal does *not* prevent Swift from building language mechanism to allow for this type of behavior though. The fact is, Swift APIs are heavily value or value semantics so the lack of inheritance on classes is not going to be the primary reason you cannot monkey patch something.</div><div class=""><br class=""></div><div class="">What this proposal does say is this: there is no “safe” way to achieve this type of behavior that the API authors either intentionally left out or left out because of an omission. </div><div class=""><br class=""></div><div class="">If you are subclassing a class in Swift, under this proposal, you can be sure of one thing: the author explicitly made it so you’d be able to. We can argue if they did so with diligence, but that’s mostly immaterial to the discussion.</div><div class=""><br class=""></div><div class="">The fact is, in order to allow monkey patching, Swift is going to need to answer many questions that it still has yet to answer, such as how reflection is really going to work. However, with these more restrictive defaults, it’s possible to extend the language to provide runtime monkey patching that can be more easily audited both in source code and at runtime. Instead of API authors just seeing crashes in their libraries and not realizing that someone swizzled a method, we would now be able to mark who did the swizzling and which functions were actually swizzled.</div><div class=""><br class=""></div><div class="">An example of how this *could* look would be something like this:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">struct Person { /* This is defined in module A */</font></div><div class=""><font face="Menlo" class=""> // a bunch of fields</font></div><div class=""><font face="Menlo" class=""> var birthDate: Date { get set }</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><font face="Menlo" class=""> func calculateAge() -> Int { return 12; }</font></div><div class=""><font face="Menlo" class="">}</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class="">Obviously there is a bug in `calculateAge`. How could we fix it? Well, in your app framework (or some other target as needed) as we don’t have the ability to fix module A directly:</div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><font face="Menlo" class="">extension Person {</font></div><div class=""><font face="Menlo" class=""> @replaceMethodImplementation func calculateAge() -> Int { /* better implementation */ }</font></div><div class=""><font face="Menlo" class="">}</font></div><div class=""><br class=""></div><div class="">This would require support within the Swift language and tooling. For one, we’d need the non-optimized code to be distributed so that code within module A used this new implementation of `calculateAge`. However, this is the direction I’d much rather see Swift go. The ability to annotate code properly as monkey patches so we can audit them, track them, version them, and identify them clearly both at compile time and runtime.</div><div class=""><br class=""></div><div class="">I’m all for Swift getting the right underlying model. After that, we can address a better way to provide the necessary means to monkey patch and change behavior, but first the fundamentals need to be nailed properly.</div></div></blockquote><div style="direction: inherit;"><br></div><div style="direction: inherit;">Agreed, but we need to get ourselves some metrics and not to be afraid to considered annoying non true believers :). As more coders use Swift in their apps for some portions or the entirety of their codebase, are we seeing less bugs? When will it be proper to collect the data in a productive non biased way? I think it'll be very interesting as more stats are available other than LOC ones.</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">We desire to have Swift run in all possible scenarios, complex video games included, and being a heavily value type based language with many built-in components using CoW semantics (sizeable in memory copies when some coders may forget it will happen). There is a reason why academia and a lot of coders back then we're pushing people towards reference types and pass by reference semantics and away from how C dealt with big structs and function pointers to achieve similar features.</div><div style="direction: inherit;"><br></div><blockquote type="cite"><div><div class=""><br class=""></div><div class="">-David</div></div></blockquote></body></html>