Это, пожалуй, уже четвёртая или пятая вводная статья по прологу на хабре с плюс-минус одинаковыми примерами, на которых далеко не уедешь. Решить условный судоку, примеры кода для которого размазаны по всему интернету, легко, но стоило мне попробовать решить головоломку посложнее из одной из компьютерных игр — мозгов, чтобы описать модель, не хватило без опыта-то.
Ок, допустим, я заинтересовался и хочу запрыгнуть в поезд логического программирования. При этом я пока что не видел ни одной статьи, которая бы подробно отвечала на следующие вопросы:
Каково состояние языка и отрасли сейчас? Компиляторы/интерпретаторы, диалекты, как часто выходят новые версии и т.д. (читайте — «живое» ли оно ещё).
Рекомендуемые книги, курсы? Насколько они свежие и соответствуют текущим реалиям?
Есть ли конкретные опенсорс-проекты, в которых пролог используется? Думаю, может быть полезно, если захочется подсмотреть best practices.
Зачем было писать какой-то сайт-лоадер? Движок QML и так поддерживает network transparency и может грузить файлы прямо из сети.
По-хорошему, конечно, нужно как минимум сделать свой фреймворк вместо Qt Quick и для начала запретить импортировать что-либо, кроме него.
Нет никакого смысла держать два браузера. И пытаться встроить движок QML в существующие тоже. Вместо этого нужно делать наоборот: если урла указывает на QML, то грузить его, если же HTML, то можно этот HTML показывать в том же браузере через qml-ный WebView.
У меня тоже Dash Pro, и всё в порядке с качеством воспроизведения с телефона, как и с качеством подключения блютус. Лично у меня описанные проблемы были с кикстартеровской версией Dash.
На самом деле я просто хотел убедиться, что семантика 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, покрытие кода тестами.