Это не проблема IDE, это лечиться настройками DE (Desktop Environment).
Вангую что у вас выставлена раскладка на каждое окно. Можно выставить например на приложение или глобально, и проблема уйдёт.
Да такой случай может быть, но это не проблема, ибо если у разработчика тесты проходят, а на CI нет, то понять что проблема в phpunit.xml не так сложно, и они тут же его приведут к общему виду. И снова нет проблемы, и снова всем удобно.
Это очень просто. Например у нас есть CI и для него нужен специальный printer, и он должен включатся по умолчанию, что бы не делать лишних телодвижений. При этом большинство использует phpstorm для запуска тестов, и ему не столь важно какой по умолчанию стоит printer. Но есть человек который запускает тесты из консоли, и ему удобно использовать стандартный принтер для консоли, и вот что бы ему каждый раз при запуске тестов не прописывать нужный printer, он может положить рядом изменённых phpunit.xml который заменит при исполнении phpunit.xml.dist и будет использоваться, и теперь ему не нужно каждый раз дописывать опции при запуске тестов.
Вопрос о том как пользователи будут использовать ваш продукт очень важен, без этого нельзя. Но всё же при тестовом задании для от программиста(если говорить о бэкэнде) требовать таких вещей странно.
И в первую очередь по тому что если разбираться как и кто будет использовать эту систему, то не может не возникнуть вопроса, а зачем писать своё? Есть ли готовые решения? А какую проблему должен решать наш продукт? А есть ли такая проблема? А кто пользователи? И так далее и тому подобное. В итоге ни одно тестовое задание не будет выполнено, ибо оно ни кому не нужно и не имеет смысла его делать.
Если нужно просто отфильтровать список по правам, понятно что никакй пролемы нет. Я говорил как раз о другом случае.
Представим что у нас есть список элементов E, к этим елементам можно применять действия С и В. При этом у пользовател могут быть права на действиа С только для некоторых элементов, а для других прав на действие С у него нет.
API+SPA это отличный подход. Но это не серебряная пуля.
Например простейшая с точки зрения адмики вещь как проверка прав доступа к ресурсу, для отображения или нет в списке элементов, ссылки на редактирование или просмотр. Для такой простой вещи нужно передавать права либо вместе с ресурсами, либо отдельно, либо реализовывать первичную проверку на стороне фронта.
И в этот момент этот простой CRUD уже не так элегантно выглядит в связке API+SPA.
Как я понял тут вопрос в том можно ли как-то анализировать с учётом сторонних библиотек подключаемых через composer. Дело в том что зависимости устанавливаемые через composer не хранят в репозитории проекта.
У нас получается так что анализ работает, но если встречается код зависимый от сторонних библиотек, то всплывает множество ошибок «такой-то класс не найден».
Если понять статичные методы "заменяющие" именованные конструкторы я могу, то вот вызывать что либо в себе эти методы никак не должны, тем более статические, ибо тут уже будет бешеная связанность кода, которую поддерживать будет вообще не возможно.
Основное предназначение — что бы невилировать время бутстраппинга приложения
По моему именно эту проблему человек хотел решить тем что у него будет 1 read-only объект в shared memory. Да в подходе php-pm будет несколько копий объекта на каждый процесс, но время на его чтение с диска будет потрачено 1 раз, на запуск сервиса, а не на каждый запрос.
По поводу reactphp и amphp.
Я пока глубоко не копал amphp, но на первый взгляд они с reactphp похожи, так как amphp так же построен вокруг event loop. Хотя реализация у них разная, основная идея по моему у них схожа.
Так что я думаю что они будут развиваться параллельно.
Если хочется хранить только read-only объекты между запросами, то можно использовать reactphp, phppm или нечто подобное. Именно shared memory они не дают, но позволяют инициализировать окружение 1 раз и потом просто обрабатывать запросы.
Стандарты кодирования, нужны что бы легко писать код, и не задумываться о стиле.
Поясню, у вас все названия переменных через _, методов тоже, и вероятно ещё куча мелочей. И есть стандарт, которому все популярные библиотеки следуют, и большинство проектов в целом так же приходят к нему, все го знают. Я как рядовой разработчик тоже его знаю, и привык писать именно так, т.е. без задней мысли буду называть метод так: «someMethod», в IDE так же есть правила автоформата для стандарта, и эти часто пользуются люди, что бы не пропускать мелочи в стиле кодирования.
И теперь когда я, захочу помочь в развитии вашего проекта, мне нужно будет переучиваться, перенастраивать окружение, переучиваться писать всё по стандарту. Это пустая трата времени, это ведь не несёт в себе ценности для меня, не даёт новых знаний, новых навыков. И многие тупо не будут помогать проекту если им нужно будет таким заниматься. И пойдут люди помогать другим проектам.
Вот в кратце суть стандартов кодирования, зачем они и чем полезны.
Да к сожалению от симфони там не так много.
Плюс бегло глянув код, заметил несколько, на мой взгляд, странных решений.
Одно из них это некий контейнер который реализует ArrayAccess, и собственно далее просто туда напихиваются значения, в том числе kernel, events, и т.д. Ну и используются так же. Это на мой взгляд не лучший способ.
Но страшнее то что они, судя по всему, любят синглтоны, и статические функции, которые выделены в трэйты.
Судя по всему тестировать такой код будет сложновато.
Собственно и тестов у них не много. А для модуля kernel, нет вовсе, хотя думается мне это важная часть проекта.
Честно сказать глянув в код, я несколько расстроен. И после этого очень скептически смотрю на будущее этого проекта
Как у вас получается соотносить синтаксис и строгую типизацию?
Это две абсолютно не связанные вещи. Строгая типизация это не признак синтаксиса, это признак языка.
По поводу кода, PHP написан на C, откуда там макросы из C++? На плюсах можно только расширения писать, но не основной код языка PHP.
Ну для обфускации php кода можно использовать сторонние библиотеки специально для этого предназначенные (ZendGuard, ionCube, etc). Раз есть возмножность подключать php экстеншены, то можно использовать их.
Плюс открытые исходники возможно привлекут сторонних разработчиков, так же этому поспособствует кроссплатформенность.
На мой взгляд у проекта с открытыми исходными кодами больше шансов взлететь в подобной нише.
Вангую что у вас выставлена раскладка на каждое окно. Можно выставить например на приложение или глобально, и проблема уйдёт.
Работает отлично.
Не баш, потому что это просто менее удобно.
И в первую очередь по тому что если разбираться как и кто будет использовать эту систему, то не может не возникнуть вопроса, а зачем писать своё? Есть ли готовые решения? А какую проблему должен решать наш продукт? А есть ли такая проблема? А кто пользователи? И так далее и тому подобное. В итоге ни одно тестовое задание не будет выполнено, ибо оно ни кому не нужно и не имеет смысла его делать.
Представим что у нас есть список элементов E, к этим елементам можно применять действия С и В. При этом у пользовател могут быть права на действиа С только для некоторых элементов, а для других прав на действие С у него нет.
Как быть в таком случае?
Например простейшая с точки зрения адмики вещь как проверка прав доступа к ресурсу, для отображения или нет в списке элементов, ссылки на редактирование или просмотр. Для такой простой вещи нужно передавать права либо вместе с ресурсами, либо отдельно, либо реализовывать первичную проверку на стороне фронта.
И в этот момент этот простой CRUD уже не так элегантно выглядит в связке API+SPA.
У нас получается так что анализ работает, но если встречается код зависимый от сторонних библиотек, то всплывает множество ошибок «такой-то класс не найден».
По моему именно эту проблему человек хотел решить тем что у него будет 1 read-only объект в shared memory. Да в подходе php-pm будет несколько копий объекта на каждый процесс, но время на его чтение с диска будет потрачено 1 раз, на запуск сервиса, а не на каждый запрос.
По поводу reactphp и amphp.
Я пока глубоко не копал amphp, но на первый взгляд они с reactphp похожи, так как amphp так же построен вокруг event loop. Хотя реализация у них разная, основная идея по моему у них схожа.
Так что я думаю что они будут развиваться параллельно.
Поясню, у вас все названия переменных через _, методов тоже, и вероятно ещё куча мелочей. И есть стандарт, которому все популярные библиотеки следуют, и большинство проектов в целом так же приходят к нему, все го знают. Я как рядовой разработчик тоже его знаю, и привык писать именно так, т.е. без задней мысли буду называть метод так: «someMethod», в IDE так же есть правила автоформата для стандарта, и эти часто пользуются люди, что бы не пропускать мелочи в стиле кодирования.
И теперь когда я, захочу помочь в развитии вашего проекта, мне нужно будет переучиваться, перенастраивать окружение, переучиваться писать всё по стандарту. Это пустая трата времени, это ведь не несёт в себе ценности для меня, не даёт новых знаний, новых навыков. И многие тупо не будут помогать проекту если им нужно будет таким заниматься. И пойдут люди помогать другим проектам.
Вот в кратце суть стандартов кодирования, зачем они и чем полезны.
Плюс бегло глянув код, заметил несколько, на мой взгляд, странных решений.
Одно из них это некий контейнер который реализует ArrayAccess, и собственно далее просто туда напихиваются значения, в том числе kernel, events, и т.д. Ну и используются так же. Это на мой взгляд не лучший способ.
Но страшнее то что они, судя по всему, любят синглтоны, и статические функции, которые выделены в трэйты.
Судя по всему тестировать такой код будет сложновато.
Собственно и тестов у них не много. А для модуля kernel, нет вовсе, хотя думается мне это важная часть проекта.
Честно сказать глянув в код, я несколько расстроен. И после этого очень скептически смотрю на будущее этого проекта
Строгой типизацией стоит называть режим строгой типизации который можно включить php.net/manual/ru/functions.arguments.php#functions.arguments.type-declaration.strict
И я думаю SamDark именно его и имел ввиду.
Это две абсолютно не связанные вещи. Строгая типизация это не признак синтаксиса, это признак языка.
По поводу кода, PHP написан на C, откуда там макросы из C++? На плюсах можно только расширения писать, но не основной код языка PHP.
Они есть и очень очень давно.
Плюс открытые исходники возможно привлекут сторонних разработчиков, так же этому поспособствует кроссплатформенность.
На мой взгляд у проекта с открытыми исходными кодами больше шансов взлететь в подобной нише.