<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Dec 17, 2015, at 11:21 PM, Gergely Orosz via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div dir="ltr" class="">(forwarding a discussion on Swift reflection from swift-users)<br class=""><br class="">It seems there is no disagreement on how reflection is something we would want in Swift. Given that until this is part of the language, it will be a blocker for several types of projects - both mocking frameworks, and data modeling runtime (as Jens Alfke mentioned) - I would be keen to understand the constraints swift wants to have in place so we can put a proposal together.<div class=""><br class=""></div><div class="">Specifically:</div><div class="">- Regarding interfaces, is there any direction or proposal on the interfaces to be used for reflection, or is this up for discussion?<br class=""></div></div></div></blockquote><div><br class=""></div>It is up for discussion.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">- Regarding security, what model would the goal be? Would something like the .NET security model (classes declaring security critical attribute cannot be accessed using readwrire reflection be suffcient? Details on this: <a href="http://bit.ly/1RVQc5J" class="">http://bit.ly/1RVQc5J</a> ). To my knowledge .NET has the most tight reflection rules in place, all other popular typed languages (e.g. Java, Ruby) are all more relaxed.<br class=""></div></div></div></blockquote><div><br class=""></div><div>The reflection system will not allow write capabilities by default. You will *definitely* have to opt in to that with something like dynamic.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">- Would secrecy also be a language goal on top of security - e.g. the ability to disallow even read reflection for certain members?</div></div></div></blockquote><div><br class=""></div><div>It is very likely that most kinds of reflection will be opt-in — if nothing else, we are very concerned about the binary-size hit of including runtime descriptions of every declaration in the program.</div><div><br class=""></div><div>John.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">- Gergely</div><div class=""><br class=""><div class="gmail_quote">---------- Forwarded message ----------<br class="">From: <b class="gmail_sendername">Joe Groff</b> <span dir="ltr" class=""><<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>></span><br class="">Date: 17 December 2015 at 22:07<br class="">Subject: Re: [swift-users] Reason for Swift not having readwrite reflection<br class="">To: Gergely Orosz <<a href="mailto:gergely.orosz@gmail.com" class="">gergely.orosz@gmail.com</a>><br class="">Cc: <a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a><br class=""><br class=""><br class=""><div style="word-wrap:break-word" class=""><span class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 17, 2015, at 10:54 AM, Gergely Orosz via swift-users <<a href="mailto:swift-users@swift.org" target="_blank" class="">swift-users@swift.org</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">As a user of swift, building projects on top of it, the single biggest limitation I've come across is that <b class="">all </b>my unit tests are significantly more bloated compared to Objective C... because mocking & stubbing is not possible due to the static nature of the language and that readwrite reflection is not supported.<div class=""><br class=""></div><div class="">I did some research and apart from C++ and C I couldn't find any other popular language that does not support readwrite reflection (here's a post I wrote on the topic: <a href="http://bit.ly/1PbgSys" target="_blank" class="">http://bit.ly/1PbgSys</a> ).</div><div class=""><br class=""></div><div class="">Not having readwrite reflection makes it impossible to create any mocking frameworks for unit testing, which is a very common tool in the testing world. Without this we're left with using dummies and fakes - for now creating them manually, in the future I'm sure there will be plugins that support generating these from e.g. protocols.<br class=""></div><div class=""><br class=""></div><div class="">The iOS community seems to be somewhat behind when it comes to automation compared to other languages and platforms - and in its current version Swift seems to make the barrier to entry even higher compared to Objective C, where mocking and stubbing is a possibility due to the dynamic nature of the language.</div><div class=""><br class=""></div><div class="">Could anyone shed some light on why the decision was made to leave this feature out? Is it just a feature that due to complexity will be pushed for later? Or is it a security consideration?<br class=""></div></div></div></blockquote><br class=""></div></span><div class="">Yes, yes, and yes. Better reflection is something we'd like to support eventually, and a lot of the necessary metadata is already present at runtime, but not exposed. Designing interfaces takes time, and there are also security and secrecy concerns regarding what ought to be reflected, so there needs to be language design as well to control what is available to runtime reflection. All that said, runtime reflection is not the only way to approach mocking and stubbing. Swift's as static as you write it; if you define your component interfaces using protocols and generics, those protocols can be conformed to with mock or stub implementations without any need for runtime hacking.</div><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">-Joe</div></font></span></div></div></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=hWKWvOREWCPT32eVzNXOV7yIWXgGOvlMtgjKbOieJnbQ1MSLeJyEoFAnq2u4c2Bk-2B4-2BxfE8-2BrWl-2FGgODeRvozkDpmjZ7S2aXj1hCGXRECEdi9FlUeJUIp56r8GjpA5adfpjFromSqx-2FEWcgIA2uchqel19MCpj-2FaS2r4pAIoDrx2nx5qm-2FjkYCCRDwWJUYVtygK6C4ZDfG5a1c1zIch84iqvaoL8TRzZleDkDXNbjdw-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>