Textures and patterns of Altos de Chavón

On our way to Saona island we also visited pseudo-old city of Altos de Chavón. Point is this city was built from 1976 to 1992, but looks as if Columbus personally laid the city. Mixed impression, honestly. The city doesn't have a general idea. However, this lack of uniformity opens an unexpected advantage: a huge ton of beautiful textures and patterns underfoot and around.

Tags: photo, vacation, dominican republic, texture, pattern

Short stories from Dominican Republic

I haven't had a proper vacation since 2015 (if not counting those I spent on university exams and St. Petersburg ethnographic trips), that last time was in Bulgaria, in Sunny Beach which lies between Burgas and Varna. That city was a slightly more european than Yevpatoria and Gursuf that I'd been many times before. That's why that city didn't enrich my cultural and ethnographic baggage.

All subsequent vacations, as I mentioned before, I spent in St. Petersburg, and quite naturally it resulted in my relocation to this city.

Nevertheless, one should have a proper rest, because burnout isn't a myth and always sneaks up unnoticed. Thus strategic decision was made: next vacation should be at sea. My cherished dream was Dominican Republic — don't know why, pretty photographs maybe like in that old Bounty ad.

And this is exactly what happened. I found a good adults only-hotel (didn't mean really, but cool) with nice and not very crowded beach. It turned out to be Punta Cana city (Bavaro area). During this vacation I found a new passion — papaya and basically spent the entire vacation quite hedonistically and just a little bit snobbish.

Tags: photo, vacation, dominican republic

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.

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.

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
More posts