Можно как монитор использовать будет) Но там же есть обратная совместимость, пусть и не совсем бесшовная.

yeswolf подскажите, планируется ли добавить подсветку файлов с ошибками навигаторе проекта? Сейчас легко можно поменять что то в одном файле и при компиляции обнаружить что в нескольких других файлах появились ошибки.

Приветствую. Я тот самый Евгений. В расшифровке подкаста нет кода, но могу предложить мою статью на похожую тему. В ней есть примеры.

У меня установлен билд 2019.1. Но попробую еще раз, на более свежей сборке.

Нет. Находил советы почистить кэш и запустить сборку на реальном девайсе. Что я только не делал, он не подчёркивает их. И вообще некоторые ошибки показывает, но примерно 70% я могу увидеть только запустив сборку. Это обескураживает. Есть вопрос на SO, где люди каждый год в комментарии отписываются, что все еще не работает. Вы там даже отвечаете) stackoverflow.com/questions/36249535/how-to-immediately-see-swift-errors-in-appcode

Когда наконец appcode будет хоть как то выделять символы которых нет в проекте? Я могу написать название класса которого нет, или метод. И это будет просто белый текст. Очень легко пропустить. Наверное только из за этого я до сих пор на Xcode.

Замечение 1. Если, учитывая критику паттерна синглтон, вы решили заменить его, ну например, на UserDefaults, то применительно к данной ситуации, вырисовывается все та же неявная зависимость.

Странный пример. Хранение состояния в объекте(временном хранилище) и в UserDefaults(постоянном) совершенно разные вещи. Если человек может заменить одно на другое из архитектурных побуждений, ему рано заниматься архитектурой. Лучше почитать «Совершенный код».

… вырисовывается все та же неявная зависимость

Это верно только в том случае если использовать UserDefaults.standard, который тоже синглтон. Вы заменяете один синглтон на другой, конечно ничего в плане зависимостей не поменяется. Но UserDefaults тоже можно внедрять в класс, тогда все будет хорошо.

Да, разумеется. Только вот так:

return try optional1.flatMap { x in try optional2.map { try transform(x, $0) }}

Использовал явное извлечение, как раз что бы сделать функцию более понятной.

Вы правы, это неоднозначно. Auth возвращает объект, осуществляющий запрос к серверу. Он игнорируется в примере. Можно рассматривать это как преобразование данных. Но для читаемости, можно использовать явное извлечение.

Вообще есть лекции и семинары. На первых лектор доносит материал и считается что задавать в этот момент вопросы не стоит, так как это сбивает темп, вносит шум. На семинарах как раз на оборот, нет лекции, есть только диалог.

Как бывший студент и действующий лектор я честно не понимаю ценности лекции. Это атавизм, времен когда книги были дифицитом, а другого способа распространения вообще небыло. Сейчас можно записать онлайн курс или просто дать студентам список литературы для ознакомления. И преобразовать все лекции в семинары, когда студенты ознакомившись с материалом уже могут его обсуждать, задавать вопросы и так далее.

Печатаю тут без проблем. Никаких лагов не замечено.

У меня на сафари единственное отличие этого треда от других это время загрузки с нуля. Кстати с 5ю отрытыми вкладками, потребление памяти < 300 МБ

Делай это браузер проблем бы небыли вообще. Но и вручную это сделать можно.

Размер элемента в нем можно, что вызовет лайаут вложенных элементов. Вообще изменение размера окна это не такой уж и проект сайенс, просто надо пересчитать по цепочке легату для всех вложенных элементов. Это чистая математика.

На мобильных платформах нормальная работа таблиц строится по принципу держим в памяти столько ячеек, сколько входит на экран. А при навигации куда либо, просто перестраиваем их. Это не так и сложно.

Ну так я об этом и написал.

Вообще вся тема последнего времени о том что все принципы SOLID должны безукоснительно соблюдаться в корне не верная. В той же книге говорится о том, что все они должны быть применены там где есть проблема. Тот же принцип единой ответственности, стоит применять его только к тем классам, которые вы реально меняете то по одной причине, то по другой и это реально увеличивает риск ошибок в конкретном проекте. Если это не так, то и беспокоиться не стоит. И в этой же книге говориться, что прогнозировать эту проблему на стадии проектировки могут только очень опытные архитекторы, а остальные должны подгонять код под эти принципы только когда уже проблема всплыла иначе очень лего получить больше вреда, чем пользы от оверинженеринга.