Дело не в ViewBuilder, а в протоколе View, который имеет один ассоциированный тип для body, а значит его нельзя положить в коллекцию без заворачивания в AnyView. Вместо коллекции используется кортеж завернутый в TupleView. Кортежи не поддерживают переменное количество аргументов, отсюда необходимость набора методов buildBlock() с определенным количеством дженерик аргументов.
Остается вопрос — зачем вообще в View ассоциированный тип? Официального ответа от Apple пока нет, но вот тут обсуждались некоторые возможные причины, среди которых главная — оптимизация производительности.
Конечно, в основе идеи ООП лежат объекты реального мира и их взаимодействия. Но это лишь аналогия. К сожалению, человеческий разум, часто, цепляется за привычное и продолжает жить аналогиями, вместо создания новых абстракций. В этом вероятно кроется причина неприятия ООП. В ФП, напротив, мы работаем с данными, выделять данные из объектов реального мира оказывается проще, чем группировать эти данные в осмысленные структуры наделенные поведением.
Сущности реального мира проявляются в ООП только в виде ограниченных абстракций — объектов доменной области, которые составляют, условно, 1% от общего количества объектов программы. Так как для работы с объектами доменной области приходится создавать объекты-помощники, которые сами по себе с доменной областью не связаны (см. Pure fabrication), и именно поэтому их легко переиспользовать в других частях программы или вообще в другом проекте.
Новички в ООП часто прямо описывают все поведение в объекте доменной области и получают god object, который невозможно переиспользовать и сложно сопровождать.
Ещё одна проблема возникает при включении объекта в окружение. В этом случае часто возникает неопределенность ответственности при описании взаимодействия двух и более объектов. Например, при столкновении двух объектов типа «мяч», у какого из объектов вызвать метод, мяч1 ударить мяч2 или мяч2 ударить мяч1?
Построение абстракций ООП на основе сущностей реального мира — одно из самых частых заблуждений в ООП (вроде бы его привнес кто-то из авторов какого-то учебника). Чтобы развеять это заблуждение, были сформулированы наборы шаблонов (GoF&co) и принципы «правильного» проектирования (SOLID и GRASP).
ООП создавалось для управления сложностью, разбиения программы на переиспользуемые «кирпичики». Объект в ООП — это набор операций над неким общим состоянием.
Скорее всего он никогда и не будет способен летать без опорных данных с земли, но этого и не требуется. В Европе большинство аэропортов поддерживают автоматическую посадку. Кроме того мы говорим о теоретической возможности разработать самолет-«самолет» на данном этапе развития технологий, и производители самолетов уже работают над этим. А нехватка пилотов будет стимулировать спрос на данную технологию.
На любой удачный исход можно найти неудачный (и наоборот) со сходными обстоятельствами. Лучше приводить конкретные случаи, где автопилот бы не справился. Иначе сложно что либо возразить.
Ну Ан-2, все же, старая машина. Я же имею в виду современные самолеты с высокой степенью автоматизации (вроде Airbus A380). Чем сложнее управление, тем выше требования к мастерству пилотов (и бортинженера).
Правильное решение можно принять обоснованно — на основании опыта и существующих инструкций, правда это будет уже предвиденная ситуация, или случайно. В действительно непредвиденной ситуации, которой раньше не происходило (например особенности аэродинамики в определенном режиме полета не выявленные в ходе разработки и испытаний) — вероятность правильного решения 50%.
Большую часть ЧП создают как раз человеки, нарушая установленные инструкции (например игнорируя показания погодного радара). В непредвиденной ситуации у человека очень мало шансов принять правильное решение (чаще принимаются неправильные). Сейчас инструкции есть на любую ситуацию, как раз на основании ошибок человеков в прошлом.
А вот интересно, когда ТМ сбросит импульс и сформирует достаточно плотные комки, можно ли ожидать какого-то нового неизвестного фазового перехода? При описании тепловой смерти Вселенной этот момент как-то упускается. Может Итану вопрос задать?
Сомневаюсь, что слабого взаимодействия будет достаточно для формирования объекта соизмеримого со звездой. Думаю, в лучшем случае получится некое гало диаметром в несколько миллионов световых лет, подобно гало из темной материи. Однако последнее формируется за счет обмена импульсом с обычной материей через гравитацию.
Для образования небесного тела или звезды одной гравитации недостаточно, вторым условием является способность материи кучковаться, которая является следствием способности частиц взаимодействовать между собой и обмениваться импульсом. Поэтому нельзя создать звезду из фотонов (только черную дыру), они просто разлетятся. С нейтрино та же проблема — очень слабое взаимодействие с чем либо, именно по этой причине нейтрино рассматривали как кандидата на роль темной материи.
С пылью — точно нет, так как пыль переизлучала бы фотоны на определенной частоте, она это и делает в пыле-газовых облаках.
Можно предположить некий процесс «старения» фотона с потерей им энергии (привет закону сохранения энергии). Не уверен, но похоже «старение» фотона никак не отличить от эффекта Допплера современными методами измерений.
ViewBuilder, а в протоколеView, который имеет один ассоциированный тип дляbody, а значит его нельзя положить в коллекцию без заворачивания вAnyView. Вместо коллекции используется кортеж завернутый вTupleView. Кортежи не поддерживают переменное количество аргументов, отсюда необходимость набора методовbuildBlock()с определенным количеством дженерик аргументов.Остается вопрос — зачем вообще в
Viewассоциированный тип? Официального ответа от Apple пока нет, но вот тут обсуждались некоторые возможные причины, среди которых главная — оптимизация производительности.Ответил ниже https://m.habr.com/ru/post/448026/comments/#comment_20026648
Новички в ООП часто прямо описывают все поведение в объекте доменной области и получают god object, который невозможно переиспользовать и сложно сопровождать.
Ещё одна проблема возникает при включении объекта в окружение. В этом случае часто возникает неопределенность ответственности при описании взаимодействия двух и более объектов. Например, при столкновении двух объектов типа «мяч», у какого из объектов вызвать метод, мяч1 ударить мяч2 или мяч2 ударить мяч1?
ООП создавалось для управления сложностью, разбиения программы на переиспользуемые «кирпичики». Объект в ООП — это набор операций над неким общим состоянием.
немножко нарушает условие задачи ;)
А вот интересно, когда ТМ сбросит импульс и сформирует достаточно плотные комки, можно ли ожидать какого-то нового неизвестного фазового перехода? При описании тепловой смерти Вселенной этот момент как-то упускается. Может Итану вопрос задать?
Можно предположить некий процесс «старения» фотона с потерей им энергии (привет закону сохранения энергии). Не уверен, но похоже «старение» фотона никак не отличить от эффекта Допплера современными методами измерений.