Если вы имеете ввиду создание транспиллера PHP -> Golang, то мне кажется это невыполнимая задача.
Для начала нужно определиться:
— что делать с нестрогой динамической типизацией PHP?
— что делать с наследованием методов? (в Go нет класического ООП и метод родительской структуры не будет вызывать переопеределенный метод из дочерней)
Ну и главный вопрос зачем?
Если стоит выбор на чем писть Go или PHP, Go выбирают там где нужна многопоточность или большая производительность чем PHP. Транспиллер не решит эти проблемы.
Идея классная. Как я понял встраеваемый аналог авторизации privat24. Сам всегда авторизуюсь по qr.
Будет ли монетизация?
А вот и аналог: auth0.com/...ation/guardian/user-guide
Посмотрите в сторону centrifugo. Воркер по мере выполнения отправляет сообщения в centrifugo, а она уже по сокетам рассылает сообщения на клиенты.
Да вы правы, правильно поставленный вопрос это уже половина ответа. Я на самом деле в поисках тех проблем, которые возможно было бы решить с помощью визуализации в виде графа. Зависимости между классами будут видны очень наглядно, особенно будут выделяться сильно связанные участки. По поводу дубликации кода, боюсь графы тут не помогут, но над этим я еще подумаю. Также планирую сделать граф наследования, точнее он у меня уже есть, нужно только его вывести. Как будет выглядеть интерфейс приложения, я еще не представляю, думаю он как раз зависит от тех проблем которые будет нацелен решать.
Кстати нашел еще один интерестный способ перенаправить пользователя из браузера в ide.
Отправить пользователя на http://localhost:63342/api/file/?file=relative/path/to/file&line=22
Когда стартуют idia ide они запускают локальный сервер, api которого мы можем использовать.
Плюс такого подхода в том что нужно знать только относительный путь к файлу в проекте.
А минус в том что если в ide не открыт нужный проект, файл не откроется.
phpstorm://openFile=path-to-file.в моем случае нежелательно. Тут нужно передавать полный путь к файлу, а я не могу знать в какой папке у пользователя размещен проект, и в общем то не должен. В upsource эта проблема каким-то образом решена.
На данный момент зафиксировать нельзя, но в целом это легко реализовать. С легаси кодом не все так просто. Например если не будут указаны типы параметров, и возвращаемые типы, хотя бы с помощью phpdoc, в таких случаях сильно затрудняется статический анализ кода.
Пока это только прототип. В ближайшее время я планирую сделать lazy load вершин. И тогда можно будет подгрузить к примеру только цепочку вызываемых методов, без лишнего так сказать шума, и нагрузки на браузер. Или к примеру можно сгрупировать данные и отобразить только взаимсвязи между классами, чтобы увидеть архитектуру вцелом.
Основная идея это поиск взаимосвязей в коде, и их визуализация.
По поводу больших графов есть идея использовать lazy load, и подгружать данные по необходимости. Визуальный интерфейс, моя слабая сторона, тут еще предстоит очень много работы.
В защиту графа могу сказать, что он может дать ответ на вопрос каким образом взаимосвязаны разные участки кода.
Тонкие указывают методы класса, толстые это вызовы методов, пунктирные имплементация. Есть идея сделать вершины методов разного диаметра в зависимости от кол-ва строк кода в методе.
Cпасибо за пример, выглядит очень интересно.
В целом планирую поддержку других языков, но это далеко идущие планы. Для начала решил сконцентрироваться на PHP, и на нем провалидировать идею.
Да про interface{} я не подумал.
Касательно рефлексии — это не лучшее решение если важна скорость.
И прежде чем думать о реализации, стоит задаться парой вопросов:
— есть ли реальная необхдимость портировать код?
— можно ли решить это более легким способом?
К примеру можно использовать github.com/deuill/go-php.
PS: Я был не прав когда сказал что это невыполнимая задача, это мега сложная задача.