Здравствуйте. Связность ограничивается тем, что всё взаимодействие ведётся через общие интерфейсы. Таким образом, модуль зависит от типа модуля-контрагента (через его API), но не от конкретной версии конкретного модуля.
Ошибка в соседнем модуле — это исключительная ситуация, которую можно (и нужно) обрабатывать. ОС проследит за тем, чтобы уведомить пострадавших.
Вариант с асинхронными каналами мне очень нравится, сам к тому же пришёл. Сюда хорошо ложатся и прокси-паттерн, и вкусности вроде async/await.
Да, именно так и предлагается делать. Проблема изменения интерфейсов актуальна, я ещё буду писать, какие конкретные действия предлагаются для её решения. Модули могут быть и закрыты, главное — открытость всех интерфейсов.
Нет, что Вы. Планируется возможность использовать любой удобный интерфейс в любом мессенджере. В том числе — и использование разных окошечек по старинке, кто ж такое запретит. Аналогично, если за анализ и подсветку синтаксиса, представление структуры проектов, запуск компилятора/отладчика, отрисовку окна IDE и т. д. отвечают разные модули, нет проблемы с тем, чтобы использовать общие хоткеи и даже общий интерфейс, если это удобно.
Простой ответ — «никак», см. пункт 8.
Сложный — «внутри объектных обёрток». Но, конечно же, это требует куда больших затрат усилий, чем простая адаптация libc или даже Qt.
Здравствуйте. Благодарю за комментарий. API под существующие ОС — дело очень хорошее. В таком виде предложенная затея тоже вполне может существовать.
На самом деле, примеров такого внедрения стандартов достаточно много: HTML, всяческие IEEE и RFC, семейство протоколов IEC. Другое дело, что исторически чаще стандартизуются узкоспециализированные или технически запутанные отрасли, а программы для простых пользователей пишутся кто во что горазд. В итоге нам до сих пор приходится вспоминать сначала, какой мессенджер нужно открыть для связи с конкретным человеком, а потом — нужно ли зажимать Shift, чтобы вставить в сообщение перевод строки.
Здравствуйте. Описанные Вами проблемы действительно существуют. Постараюсь в следующей статье показать, почему это не тот случай и где в предложенной схеме место открытости.
Добрый день. О целях я обязательно напишу более подробно в следующем посте.
Если вкратце, то цель — получить совместимость любого софта. Не на уровне «в новой версии Программа 1 поддерживает экспорт данных в формат Программы 2», а, например, на уровне возможности использовать интерфейс MS Word при работе с Гуглодокументами, если это удобно. Или через интерфейс клиента VK общаться по Skype, опять же, если это удобно. Видеть всю свою музыку из Яндекса/ВК/Ютюба/Локальной подборки в одном месте, если это удобно. Зачем? Потому что это удобно. Потому что компьютер/телефон мог бы представлять собой целостный инструмент, не поделенный на узкие зоны ответственности ограниченными приложениями. Я разовью тему в следующих постах.
Хотя, разумеется, некоторая доля развлекательного велосипедостроения тут присутствует. Все мы хотим получать удовольствие от того, что делаем. =)
Добрый день.
Насколько я могу судить, основная причина провала упомянутых Вами проектов состоит в банальной нехватке софта под них вкупе со слабой обратимостью смены платформы, что отпугивает как пользователей, так и разработчиков.
Буду рад услышать Ваше мнение на этот счёт.
Код есть на гитлабе по ссылке в тексте статьи, перепечатывать сюда не вижу смысла. Картинки есть в ролике — но да, для наглядности, наверное, стоило прицепить парочку статических.
Это люди, которым в учебнике написали: вот так объявляется массив объектов, вот так — массив указателей на объекты. Вот такой синтаксис обращается к методу объекта по его указателю. Вот так работает оператор new []. Теперь напишите программу, которая будет производить масштабирование сложной геометрической фигуры на плоскости.
В итоге человек, который не до конца понимает, что делает синтаксис, который он использует, начинает писать код, который выглядит как пример, который я дал в самом начале. Подобную ситуацию приходилось видеть не раз и не два, даже если человек честно читал учебник — увы, не все они написаны последовательно, а багаж знаний, накопленных в таких языках, как JavaScript, ещё более усложняет понимание.
Как раз справа налево. Правый корень «ед» заменяем на фразу «тот, кто ест», словарная основа остаётся. Также как «T*» читается как «указатель на T», то есть, справа налево.
Здравствуйте. Связность ограничивается тем, что всё взаимодействие ведётся через общие интерфейсы. Таким образом, модуль зависит от типа модуля-контрагента (через его API), но не от конкретной версии конкретного модуля.
Ошибка в соседнем модуле — это исключительная ситуация, которую можно (и нужно) обрабатывать. ОС проследит за тем, чтобы уведомить пострадавших.
Вариант с асинхронными каналами мне очень нравится, сам к тому же пришёл. Сюда хорошо ложатся и прокси-паттерн, и вкусности вроде async/await.
Да, именно так и предлагается делать. Проблема изменения интерфейсов актуальна, я ещё буду писать, какие конкретные действия предлагаются для её решения. Модули могут быть и закрыты, главное — открытость всех интерфейсов.
Сложный — «внутри объектных обёрток». Но, конечно же, это требует куда больших затрат усилий, чем простая адаптация libc или даже Qt.
На самом деле, примеров такого внедрения стандартов достаточно много: HTML, всяческие IEEE и RFC, семейство протоколов IEC. Другое дело, что исторически чаще стандартизуются узкоспециализированные или технически запутанные отрасли, а программы для простых пользователей пишутся кто во что горазд. В итоге нам до сих пор приходится вспоминать сначала, какой мессенджер нужно открыть для связи с конкретным человеком, а потом — нужно ли зажимать Shift, чтобы вставить в сообщение перевод строки.
Если вкратце, то цель — получить совместимость любого софта. Не на уровне «в новой версии Программа 1 поддерживает экспорт данных в формат Программы 2», а, например, на уровне возможности использовать интерфейс MS Word при работе с Гуглодокументами, если это удобно. Или через интерфейс клиента VK общаться по Skype, опять же, если это удобно. Видеть всю свою музыку из Яндекса/ВК/Ютюба/Локальной подборки в одном месте, если это удобно. Зачем? Потому что это удобно. Потому что компьютер/телефон мог бы представлять собой целостный инструмент, не поделенный на узкие зоны ответственности ограниченными приложениями. Я разовью тему в следующих постах.
Хотя, разумеется, некоторая доля развлекательного велосипедостроения тут присутствует. Все мы хотим получать удовольствие от того, что делаем. =)
Насколько я могу судить, основная причина провала упомянутых Вами проектов состоит в банальной нехватке софта под них вкупе со слабой обратимостью смены платформы, что отпугивает как пользователей, так и разработчиков.
Буду рад услышать Ваше мнение на этот счёт.
В итоге человек, который не до конца понимает, что делает синтаксис, который он использует, начинает писать код, который выглядит как пример, который я дал в самом начале. Подобную ситуацию приходилось видеть не раз и не два, даже если человек честно читал учебник — увы, не все они написаны последовательно, а багаж знаний, накопленных в таких языках, как JavaScript, ещё более усложняет понимание.
По фотографиям — да, идея фотографировать узлы во время сборки пришла уже слишком поздно, разбирать из-за этого модель теперь слишком муторно.