> On Dec 17, 2015, at 11:21 PM, Gergely Orosz via swift-evolution > <[email protected]> wrote: > (forwarding a discussion on Swift reflection from swift-users) > > 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. > > Specifically: > - Regarding interfaces, is there any direction or proposal on the interfaces > to be used for reflection, or is this up for discussion?
It is up for discussion. > - 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: > http://bit.ly/1RVQc5J <http://bit.ly/1RVQc5J> ). 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. The reflection system will not allow write capabilities by default. You will *definitely* have to opt in to that with something like dynamic. > - Would secrecy also be a language goal on top of security - e.g. the ability > to disallow even read reflection for certain members? 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. John. > > - Gergely > > ---------- Forwarded message ---------- > From: Joe Groff <[email protected] <mailto:[email protected]>> > Date: 17 December 2015 at 22:07 > Subject: Re: [swift-users] Reason for Swift not having readwrite reflection > To: Gergely Orosz <[email protected] <mailto:[email protected]>> > Cc: [email protected] <mailto:[email protected]> > > > >> On Dec 17, 2015, at 10:54 AM, Gergely Orosz via swift-users >> <[email protected] <mailto:[email protected]>> wrote: >> >> As a user of swift, building projects on top of it, the single biggest >> limitation I've come across is that all 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. >> >> 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: http://bit.ly/1PbgSys <http://bit.ly/1PbgSys> ). >> >> 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. >> >> 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. >> >> 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? > > 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. > > -Joe > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
