[swift-evolution] Readwrite reflection in Swift

[Gergely Orosz]

(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 ). 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?

- Gergely

---------- Forwarded message ----------
From: Joe Groff <jgroff at apple.com>
Date: 17 December 2015 at 22:07
Subject: Re: [swift-users] Reason for Swift not having readwrite reflection
To: Gergely Orosz <gergely.orosz at gmail.com>
Cc: swift-users at swift.org



On Dec 17, 2015, at 10:54 AM, Gergely Orosz via swift-users <
swift-users at swift.org> 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 ).

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151218/2481fe49/attachment.html>