На самом деле я просто хотел убедиться, что семантика Qt/QML в вашем PureQML сохранена. Но потом увидел вот это:
// ...
setPos(long, lat): {
// ...
}
// ...
Для Qt/QML это в принципе невалидная запись, что меня и заинтересовало.
На мой взгляд разница между одной записью и другой всё же есть. Если я правильно понял, то для вас эти две записи эквивалентны:
function foo() { }
и
foo: { }
С одной стороны вторая запись слишком похожа на binding какого-то выражения к свойству foo. Окей, допустим, вы не стали делать различия между свойствами и методами (мемберы и есть мемберы, почему бы и нет). Но в Qt/QML есть другая штука. Вот эти две записи с его точки зрения эквивалентны:
propName: jsExpression
и
propName: { return jsExpression; }
Таким образом, если мы хотим забиндить ("забайндить" не звучит, так что буду называть это забиндить) на свойство не результат выполнения блока кода, а сам этот блок кода, то в Qt/QML мы пишем как-то так:
С другой стороны вы, возможно, не стали делать различия между методами и обработчиками сигналов. Окей, тоже почему бы и нет. Фактически, единственное, что их у вас отличает, это наличие префикса on. На мой взгляд, это различие недостаточно явное. Например, предположим, у нас есть компонент Foo, описанный в Foo.qml следующим образом:
В случае же с сигналами всё работает немного иначе. Допустим, Bar выглядит так:
Item {
signal bar()
onBar: {
console.log("inner");
}
}
Потом мы его используем как-то так:
Item {
Bar {
id: _bar
onBar: { // пишем свой обработчик сигнала
console.log("outer");
}
}
onSomeEvent: {
_bar.bar() // выводит сначала "inner", потом "outer"
}
}
Другими словами, если бы вы позволяли объявить таким же образом метод, начинающийся с on, то была бы вообще полная неразбериха. А так только наполовину, на мой взгляд. Странно всё это :)
Ну ок, не заменили, а добавили. Тем не менее синтаксис новый (и на мой взгляд добавляет путаницу), причём на сайте в разделе с различиями с оригинальным QML я этого не нашёл.
Слава богу, автор пилит тулзы, а не игру.
Небось для пробной реализации какой-то игровой идеи пришлось бы сначала составлять дополнение к диз.доку, писать спецификацию на фичу по ГОСТам, аппрувить в трёх разных отделах с обходным листом и треугольной печатью из седьмого кабинета и т.д.
Мы бы даже в первую часть ещё не поиграли.
QML работает внутри обычного нативного приложения, обрабатывается специальным движком, рендерится через OpenGL, декларативность-реактивность из коробки, скриптовать можно на JS, расширять на С++.
Но мне кажется будущее всё же за github.com/nylas/N1 типа приложениями (технологии Electron, React, Flux). Кросс-платформенное, код на CoffeeScript, покрытие кода тестами.
Пользоваться им и правда не всегда удобно. Только это проблема не MPS, а устаревших прочих инструментов.
На самом деле я просто хотел убедиться, что семантика Qt/QML в вашем PureQML сохранена. Но потом увидел вот это:
Для Qt/QML это в принципе невалидная запись, что меня и заинтересовало.
На мой взгляд разница между одной записью и другой всё же есть. Если я правильно понял, то для вас эти две записи эквивалентны:
и
С одной стороны вторая запись слишком похожа на binding какого-то выражения к свойству
foo. Окей, допустим, вы не стали делать различия между свойствами и методами (мемберы и есть мемберы, почему бы и нет). Но в Qt/QML есть другая штука. Вот эти две записи с его точки зрения эквивалентны:и
Таким образом, если мы хотим забиндить ("забайндить" не звучит, так что буду называть это забиндить) на свойство не результат выполнения блока кода, а сам этот блок кода, то в Qt/QML мы пишем как-то так:
или даже
В общем, немного сложно понять, что происходит.
С другой стороны вы, возможно, не стали делать различия между методами и обработчиками сигналов. Окей, тоже почему бы и нет. Фактически, единственное, что их у вас отличает, это наличие префикса
on. На мой взгляд, это различие недостаточно явное. Например, предположим, у нас есть компонентFoo, описанный вFoo.qmlследующим образом:Потом мы его используем как-то так:
В случае же с сигналами всё работает немного иначе. Допустим,
Barвыглядит так:Потом мы его используем как-то так:
Другими словами, если бы вы позволяли объявить таким же образом метод, начинающийся с
on, то была бы вообще полная неразбериха. А так только наполовину, на мой взгляд. Странно всё это :)Небось для пробной реализации какой-то игровой идеи пришлось бы сначала составлять дополнение к диз.доку, писать спецификацию на фичу по ГОСТам, аппрувить в трёх разных отделах с обходным листом и треугольной печатью из седьмого кабинета и т.д.
Мы бы даже в первую часть ещё не поиграли.
Из серии «коней на переправе не меняют».
А будете Вы его использовать или нет, это уже дело Ваше.
Кстати, на заметку, QT = QuickTime, Qt = Qt.
Зачем, если есть QML?
Total Commander, PowerShell + ConEmu