Reason for Swift not having readwrite reflection


(Gergely Orosz) #1

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?

Thanks,

Gergely


(Joe Groff) #2

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

···

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


(Jens Alfke) #3

I also strongly want reflection, but for a different purpose: data modeling. Core Data’s NSManagedObject is an example of what can be done with Objective-C: you just subclass it and add @property declarations, and the framework takes care of implementing those properties and backing them with data from a database. I happen to work on a different database (Couchbase Lite) that has a similar mechanism that uses the same Obj-C reflection capabilities. Our CBLModel class can be used in Swift since it inherits from NSObject, but in the long run I’d prefer to be able to do this with a pure-Swift class.

I’m glad to hear from Joe Groff that this is on the road-map. This would be a good topic to discuss on the swift-evolution list; swift-users seems more targeted at using Swift-as-it-is.

—Jens

···

On Dec 17, 2015, at 10:54 AM, Gergely Orosz via swift-users <swift-users@swift.org> wrote:

Not having readwrite reflection makes it impossible to create any mocking frameworks for unit testing