Исправление Serbis, (текущая версия) :
Проблема в отсутсвии возможности полноценной интероперабельности за пределеми самого qt, или попросту крайне низкая экстенсивность. Наверняка тебе приходилось слышать такие термины как промисификация, фючеризация, реактивизация. Это когда мы берем интерфейчас какого-то внешнего апи, и путем навешивания фасада подгоняем его под концепцию работы основного фреймфорка. Если язык программирования поддерживает расширения, наподобие scala или kotlin, то это позволяет создать вообще бесшовный интерфейс между приложением и библиотечным апи. Вот как пример из андроида:
button.setReactiveOnClickListener().<stream processing>
Навесили реактивный фасад на кнопку в виде расширения. Никаких коллбеков, теперь у нас одним вызовом есть стрим с событиями нажания на кнопку, который мы можем обрабатывать, комбинировать с другими стримами и т. д. Это вот как раз и есть пример высокой экстенсиовности фреймворка. В Qt с его сигналами и слотами и очень жесткой ориентированности на ООП эти возможности очень ограничены. Т е я не могу просто так взять какую-то стороннюю библиотеку и заставить ее работать в рамках парадигмы слот-сигнал без создания очень массивного адаптера. А без такого адаптетра будет окостыливание кода, потому что придется inPlace работать с библиотекой создавая callback hell. Короче говоря пока мы работаем внутри инфраструктуры qt у нас все замечательно, но как только мы за нее выходит, начинается жесть.
Исправление Serbis, :
Проблема в отсутсвии возможности полноценной интероперабельности за пределеми самого qt, или попросту крайне низкая экстенсивность. Наверняка тебе приходилось слышать такие термины как промисификация, фючеризация, реактивизация. Это когда мы берем интерфейчас какого-то внешнего апи, и путем навешивания фасада подгоняем его под концепцию работы основного фреймфорка. Если язык программирования поддерживает расширения, наподобие scala или kotlin, то это позволяет создать вообще бесшовный интерфейс между приложением и библиотечным апи. Вот как пример из андроида:
button.setReactiveOnClickListener().<stream processing>
Навесили реактивный фасад на кнопку в виде расширения. Никаких коллбеков, теперь у нас одним вызовом есть стрим с событиями нажания на кнопку, который мы можем обрабатывать, комбинировать с другими стримами и т. д. Это вот как раз и есть пример высокой экстенсиовности фреймворка. В Qt с его сигналами и слотами и очень жесткой ориентированности на ООП эти возможности очень ограничены. Т е я не могу просто так взять какую-то стороннюю библиотеку и заставить ее работать в рамках парадигмы слот-сигнал без создания очень массивного адаптера. А без такого адаптетра будет окостцливание кода, потому что придется inPlace работать с библиотекой создавая callback hell. Короче говоря пока мы работает внутри инфраструктуры qt у нас все замечательно, но как только мы за нее выходит, начинается жесть.
Исправление Serbis, :
Проблема в отсутсвии возможности полноценной интероперабельности за пределеми самого qt, или попросту крайне низкая экстенсивность. Наверняка тебе приходилось слышать такие термины как промисификация, фючеризация, реактивизация. Это когда мы берем интерфейчас какого-то внешнего апи, и путем навешивания фасада подгоняем его под концепцию работы основного фреймфорка. Если язык программирования поддерживает расширения, наподобие scala или kotlin, то это позволяет создать вообще бесшовный интерфейс между приложением и библиотечным апи. Вот как пример из андроида:
button.setReactiveOnClickListener().<stream processing>
Навесили реактивный фасад на кнопку в виде расширения. Никаких коллбеков, теперь у нас одним вызовом есть стрим с событиями нажания на кнопку, который мы можем обрабатывать, комбинировать с другими стримами и т. д. Это вот как раз и есть пример высокой экстенсиовности фреймворка. В Qt с его сигналами и слотами и очень жесткой ориентированности на ООП эти возможности очень ограничены. Т е я не могу просто так взять какую-то стороннюю библиотеку и заставить ее работать в рамках парадигмы слот-сигнал без создания очень массивного адаптера. А без такого адаптетра будет окосталивание кода, потому что придется inPlace работать с библиотекой создавай callback hell. Короче говоря пока мы работает внутри инфраструктуры qt у нас все замечательно, но как только мы за нее выходит, начинается жесть.
Исходная версия Serbis, :
Проблема в отсутсвии возможности полноценной интероперабельности за пределеми самого qt, или попросту крайне низкая экстенсивность. Наверняка тебе приходилось слышать такие термины как промисификация, фючеризация, реактивизация. Это когда мы берем интерфейчас какого-то внешнего апи, и путем навешивания фасада подгоняем его под концепцию работы основного фреймфорка. Если язык программирования поддерживает расширения, наподобие scala или kotlin, то это позволяет создать вообще бесшовный интерфейс между приложением и библиотечным апи. Вот как пример из андроида:
button.setReactiveOnClickListener().<stream processing>
Навесили реактивный фасад на кнопку в виде расширения. Никаких коллбеков, теперь у нас одним вызовом есть стрим с событиями нажания на кнопку, который мы можем обрабатывать, комбинировать с другими стримами и т. д. Это вот как раз и есть пример высокой экстенсиовности фреймворка. В Qt с его сигналами и слотами и очень жесткой ориентированности на ООП эти возможности очень ограничены. Т е я не могу просто так взять какую-то стороннюю библиотеку и заставить ее работать в рамках парадигмы слот-сигнал без создания очень массивного адаптера. А без такого адаптетра будет окосталивание кода, потому что придется inPlace работать с библиотекой создавай callback hell.