Want to keep in touch with the evolution of the Swift language? Here are some links to help.
Join the DZone community and get the full member experience.Join For Free
Good talk and links here to keep you abreast of evolving Swift paradigms:
Last Tuesday I gave a talk at Swift London called Swifty? looking at interesting patterns emerging from the community, as well as how Swift 3 will shape idiomatic code. You can see my slides on Speaker Deck.
The talk covered several topics, so I thought I’d link to some examples for those who want to learn more.
- Phantom types
- Stateful mixins in Swift from yours truly
- Swift 3 evolution proposals
This is an even better post on namespacing:
Dear Erica, Why would you create an enum with no cases?
This is such a great question! No-case enumerations represent a fairly obscure Swift “power tool”, and one that most developers are unaware of.
The answer, in a nutshell, is that they enable programmers to establish a mini-namespace with little overhead and an assurance that you can’t accidentally create type instances. Under their umbrella, you can group static members into namespaces, build singletons, create cohesive collections of functionality with a minimum surface eliminating freestanding functions, and in one outlier case provide services built around generic types…
And this is an interesting pattern for applying private type extensions which suits well our predisposition towards exposing only designated functionality, a position which is subject to some full and frank discourse over where they’re considering it as not just a style choice but an enforced language construct, if you’ve picked up on that brouhaha; if not, we’ll put an addendum here if/when something actionable happens. In the meantime, check out
This article introduces a design pattern that I call Concealment, and demonstrates how to use the pattern in Swift code.
The Concealment pattern enables types to support novel, related functionality without adding nonessential members to their interface.
User-defined types can easily be overused in a codebase, giving more prominence to things than necessary. A common example is having a data model entity be involved with tangentially related concerns; such as validation checks, business rule processing, and display formatting. It is preferable to conceal the augmentation and usage of your types behind an API expressly built for a single responsibility, rather than expose those implementation details to all the types’ consumers…
Yep, we agree there; anything that reduces cognitive load is a Good Thing!
Published at DZone with permission of Alex Curylo, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.