Romul81
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Abs62
Вопрос по поводу дальнейшего развития программы.
Когда вы планируете прекратить поддержку версии на Qt4? И двигаться дальше...
Просто эта привязка к старым API и "синхронизация" кода со старой версией это как прицеп "Скиф" и тянущий его "Крузак". Разные уровни.
Самое критичное здесь - QRegExp. На него плюются даже разрабы Qt. Современный QRegularExpression не просто "новее", он на порядок лучше по всем параметрам. Кстати, может вам будет интересно, нашёл старую дискуссию разрабов (?) Qt по поводу необходимости внедрения нового дивжка для рег. выражений. Вкратце, они долго и безуспешно метались в попытках понять куда двигаться - то ли V8, то ли RE2, то ли PCRE. Сразу взять последний не позволяли сложности с внутренним преобразованием UTF16-> UTF8-> UTF16. С другими движками были свои заморочки. И тут случилось чудо. Разрабы PCRE в версии 8.30 добавили нативную поддержку UTF16, который сразу и подобрали разрабы Qt.
Стоит ли говорить, что новый QRegularExpression (по сути PCRE, у которого целая индустрия за плечами) и самописный кривой QRegExp - это как Мерседес по сравнению с ЗАпором (извините за штамп). Помимо человеческого синтаксиса и поддержки всех остальных бесчисленных плюшек и "сахара", он ещё и в разы быстрее. Правда, тестов в сети практически нет, но кое-что удалось найти. Причём, обратите внимание, тестируемая версия Qt ещё 5.0.0.
Почему я так заостряю на этом внимание? Вы, как никто другой знаете критическую зависимость GD от движка рег. выражений. Огромная часть функционала строится именно на нём. Причём, в самых чувствительных в плане скорости местах, таких как предобработка вывода, индексация и FTS. Уверен, что индексация для FTS на новом движке (и с переписанным кодом) будет занимать минимум в два раза меньше времени. Конечно, переписывать придётся очень много. Целые блоки кода можно будет выбрасывать, т.к. программные "костыли" нагромождались с течением времени по причине убогости QRegExp, тогда как с QRegularExpression многие вещи можно будет реализовать в рамках синтаксиса PCRE. Например, ситуация, которую описал Itkind. Можно было бы предусмотреть что-то типа теста на [\p{Hebrew}]. Если правда, то сбрасывать ограничитель до двух символов. Конечно, это можно и сейчас организовать, но гораздо большими телодвижениями.
Второй момент - это переход на новые браузерные технологии. Представьте, что больше не надо экранировать CSS. Вообще. Хотя парсить всё равно придётся, но на другом уровне - просто для того, чтоб прописать пути в ресурсах, что, естественно, гораздо легче, чем впихивать ID перед каждым селектором (а я видел CSS в словарях с тысячами селекторов). А об изоляции через увеличение специфичности можно будет забыть. Да и об ID для вторичного контента в DSL, которые только засоряют DOM. Плюсик можно организовать гораздо проще.
Я, конечно, писал уже об этом... Просто хотел напомнить о технологии Web Components. Она, кстати, претерпела некоторые изменения. Текущая версия - Shadow DOM v1. Не буду сейчас углубляться, просто приведу ссылки:
Shadow DOM v1: Self-Contained Web Components
Позвольте представить, Shadow DOM API на основе слотов
Веб-компоненты: обзор и использование в продакшне
По последней ссылке очень развёрнутая статья. Нам и половины того не надо. А нативная поддержка есть не только в Blink, но и в Webkit 10+ https://caniuse.com/#feat=shadowdomv1
В завершение, для Blink есть новое свойство CSS - contain
CSS-изоляция
CSS Containment
Как считаете, есть ли у GD такое будущее? Всецело зависит от Вас. Хотя, если развиваться в этом направлении, работы здесь для одного человека непочатый край.
|
