Hospitality crew finally came back to Saint Petersburg after a long break. Whiney, London Elektricity, MC Dynamite and other folks set the heat on four stages.+61 photographs without commentaries. Tools 70-200 mm, 35 mm.
So apparently I'm gonna be officially shooting photographs of Red Snapper concert this Saturday at Erarta Museum. Concert report will be up on Sunday.
As they say — please stand by.
Makoto, Spectrasoul, London Elektricity, Metrik and Dynamite MC including our own stars like Tapolsky, Sunchase and Vera Sue. It's illegal to miss that.
+160 photographs without comments.
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.
P.S. I might be mistaken, but in Swift 3 the behaviour was different, and timer execution did not stop like that. I'm not sure if it's correct behaviour, but anyway, in Swift 4 it's quite reasonable.
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'.
P.S. All of it relates to Swift versions 3 and 4, and may be changed in future. I'll try to not forget to update this article if anything changes (it might, as we all know).
Once I had hard time trying to sleep and decided to shoot the sunrise at our ponds.