Comments 11
Ждем кросс-JIT между PHP FFI JIT и LuaJIT с инлайнингом и прочим.
В плане общего развития - конечно интересно. Но ведь есть уже модуль для Lua: https://www.php.net/lua
Я что-то упускаю?
Всю статью я ждал ответ на вопрос "а нафига" и так и не нашел его.
Можете привести примеры зачем понадобилось внедрять LUA в PHP в реальной жизни?
У вас два скриптовых языка, в чем LUA лучше чем PHP, что требуется часть кода писать на нём?
В разделе "мотивация" старался описать. Вот:
В компилируемом KPHP полезно иметь возможность использовать динамические плагины.
Скриптовый язык - термин не точный, а скорее жаргон. Язык редко бывает интерпретируемым или компилируемым, это свойство реализации. PHP чаще всего используется с интерпретатором, а KPHP имеет только компилируемую реализацию. На KPHP можно писать десктопные приложения, игры и прочие серьёзные штучки (на PHP тоже можно, но коробочный дистрибутив в виде одного почти полностью статически слинкованного бинарника распространять там гораздо сложнее).
FFI Lua работает и там, и там. Если вы работали с компилируемыми языками, то понимаете, что там не так просто обеспечить расширяемость. Это или dlopen на отдельно собранные либы, либо встраивание какого-то интерпретатора. Вот FFI в PHP/KPHP - это как раз dlopen. И через него мы встраиваем Lua.
Так можно собрать KPHP приложение в бинарь, отдать заказчику как чёрную коробку, а расширяемость обеспечить через Lua скрипты. Так заказчику не нужны исходники приложения. Всё, что нужно - положить в правильное место скрипты.
Вообще примеров, где нативные приложения используют встроенные интерпретаторы много. Это почти все игровые движки, сервера приложений типа Nginx, софт для работы с изображениями и полно чего ещё.
Зачем же тогда нам Lua в PHP? Чаще всего, приложения на KPHP приятно тестировать на PHP. А ещё это оставляет нам простор для того, чтобы, в случае чего, было проще переходить туда-сюда, ведь наш код всегда валиден и там, и там.
Но это всё если отбросить образовательный момент. По FFI мало материалов, особенно таких нетривиальных. Неужели плохо, что их становится больше? Здесь и примеры как самому сделать, и готовая библиотека для подглядывания. :)
Вообще статья и так вышла довольно крупной и сложной, поэтому мне не хотелось дополнительно добавлять много букв об этой детали. 1-го предложения достаточно для тех, кто когда-нибудь пробовал делать нативные приложения расширяемыми. А если этого опыта нет, то это уже почти тема для отдельной статьи, ведь там больше одного подхода.
Есть ещё одна, менее очевидная причина.
Я общался с автором FFI в PHP, мы обсуждали проблемы, дизайн, производительность.
Желание такое: лучше понять применимость этой фичи, увеличить её распространение, а потом улучшить производительность за счёт JIT и некоторых других трюков.
Если мы не будем говорить о FFI и делать на нём библиотеки, он всегда будет таким, какой есть.
Всю статью я ждал ответ на вопрос "а нафига" и так и не нашел его.
А я просто прочитал статью с интересом :)
Продублирую и тут ссылочку. В этом чатике собирается сообщество KPHP.
Разработчики компилятора там тоже есть.
Встраиваем Lua в PHP через FFI