How I Learned to Stop Worrying and Love the EventLoopFuture

Low-level framework SwiftNIO developed by Apple corporation is a foundation for all major server-side Swift frameworks β€” Vapor, Kitura, Smoke.

However, none of these instruments comprehensively clarify main concepts and principles of usage of the most important part of NIO β€” EventLoopPromise and EventLoopFuture, which leads to fundamental misunderstanding and confusion, and therefore questions like β€œHow to get value from Future?” are asked in all kinds of forums and chats.

This is what we're gonna talk about today in this small tutorial.

Tags: swift, swift-nio, vapor, future, promise, EventLoopFuture, EventlLoopPromise

Why DispatchSource.makeTimerSource not working?

Say you did the following

and proceeded to your business, but the timer fired once or even not a single time. Why? It's because your timer object has been eaten by garbage collector, and when DispatchSourceTimer is deinited, it (obviously) stops itself. It's worth reminding that GC is triggered when scope closes, in our case β€” after async block fired. Therefore, if you want to regularly run certain task, you should store reference to timer object in a global storage, which would live as long as you want, but not the GC. It's also recommended to wrap access to this storage with synchronous serial queue to avoid shameful race conditions.

By the way, there might be an opposite situation: timer wouldn't destroy when you destroy all references to it. The reason is timer handler might have a strong reference to some object or self. In order to ensure it wouldn't happen, explicitly specify [weak self] in timer handler header.

Tags: programming, swift

Secret of Self in Swift

2019 update: in version 5.1 it will be possible to use Self in concrete context, and not just in protocols and protocols extensions. I will properly update this post once 5.1 is released. The rest of this post describes pre-5.1 behaviour.

Anyone who study Swift programming language surely knows what keyword self means β€” it is reference to current object inside class instance context. Completely normal stuff in almost any objective language. The tricky part begins when one deals with static methods and properties as well as with the famous Swift's protocol-oriented paradigm. We won't emphasize attention on protocol philosophy, instead let's proceed to the most interesting part, and I'm quite sure anyone had business with it.

I'm talking about calling static method from protocol extension or defining a protocol method which must return eventual type. All of that is a particular case of late static binding, and everybody may google it anytime.

It's quite straight and simple in case of commonplace static method inside class or structure β€”Β method is easily called with type name, or you just call type(of: self) which returns current type and from that you may call static methods. However when there is no concrete type yet, but only protocol and/or its extensions (i.e. metatype), language simply won't let us do it because protocol cannot contain implementation and protocol extension is not considered as concrete code, hence we get compiler error Static member 'staticMethodName' cannot be used on protocol metatype 'ProtocolName.Protocol'.

The solution is using keyword Self (exactly that, capitalized) which is a reference to eventual type conforming to protocol. Official documentation has only one mentioning of this keyword:

In that [protocol] context, Self refers to the eventual type that conforms to the protocol.

Respectively, this keyword works only in metatype context (protocols and protocol extensions), in concrete classes or structures you get error Use of unresolved identifier 'Self'.

Tags: programming, swift, self