> 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? > - 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. > - Would secrecy also be a language goal on top of security - e.g. the ability > to disallow even read reflection for certain members?
Also consider alternatives to the use cases you described—mocking and data modeling can also be accomplished by compile-time code generation, and by features like type providers that supply external type information to the compiler. Runtime reflection is definitely useful in many cases, but compile-time approaches are likely to be easier to verify and maintain, faster, and more secure. -Joe
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
