Так работать не будет. Что в в джаве, что в ноде, что в пыхе интерпретатор\вм у вас один конкретный и (в случае пыхи) каким вы индекс файл запускаете - тем интерпретатором все и обработается, т.к. по сути все остальное - это цепочка инклудов\реквайров из него. Да, там есть обратная совместимость, но такого что вот эти файлы исполняются таким рантаймом, а такие - другим - такое я не видел ни в одной экосистеме. Такое можно сделать запуская отдельный код через экзеки, но это какие то уже странные подходы
А, я понял о чем вы. Но снова не понял. PHP вполне себе успешно запускается после распаковки из зип архива, никогда не было проблем с расширениями. достаточно положить .so файлы в правильное место (в ext). На той же убунте легко поставить несолько версий пых параллельно, после чего тот же непривилигерованный пользователь может их вызывать по типу php7, php8, php81 и тд.
который вообще не видит /usr /bin и т.д
Эти папки видят все пользователи, даже бесправные, это системные папки и они прописаны в PATH. можно любому пользователю прописать любой PATH.
В общем, нет никаких хардкодных путей в самой пыхе. Они могут быть в том способе установки и настройки пыхи, которым вы пользуютесь, но не в пыхе. У меня на компе пыха лежит в C:/Tools/PHP{74,80,81}, в PATH прописана 81, но при необходимости я могу рукам вызвать любую нужную мне версию (или например в шторм прописать как интерпретатор). и весь запущенный код этой пыхой работает именно с этой версией пыхи
Не обязательно генерировать в зависимости от внешних данных. Это могут быть зависимости от конфига, от наличия определенных пакетов в вендоре (автоматический бриджинг). Кодогенерация генерирует более оптимальные для исполнения структуры (можно почитать например про роутиниг симфони, который генерирует огромную регулярку по факту в кэш, супероптимизированную)
Я упростил, да. Тем не менее это все же расширение, я про это. Сама идея - технически опенсурсная, можно также написать свое расширение под %языкнейм% (как было например с андроид студией, насколько я помню)
Т.е. фактически разница в том, что к одной системе написали годное расширение, а к другой нет, и за годное хотят деняк.
upd. попробовал поставить расширение php Для idea ultimate - работает так же моментально все после индексации. Так что тезис про преконфигуренную идею работает
я поставил какой-то топовый по загрузкам экстеншен, без него это совсем не работало.но не надо забывать,что php - это на самом деле тоже расширение для idea, иными словами phpstorm - это преконфигуренная идея
Мы сейчас обсуждаем только простой полнотекстовый поиск или все таки в том числе всякие другие поисковые возможности, анализирующие содержимое, навроде поиска вызовов функций, использования элементов языка (с учетом разного рода импортов типа *) и т.д.?
vscode делает, например, поиск использования приватного свойства класса (300 строк) настолько долго, что после phpstorm я успеваю нажать еще пару раз, думая, что оно не сработало. шторм открывает юзейджи практически мгновенно
В Глобусе регулярно пользуемся Scan&Go (тебе выдают терминал, ты им сканируешь сам все что кладешь в корзину), весьма популярная штука (судя по вечно практически пустым стендам со сканерами). На кассе только оплачиваешь + проверка всякого юридически-сложного товара (например, алкоголь, если есть - попросят паспорт и заапрувят в терминале оплату) + иногда - выборочная проверка (сотрудник сканирует часть корзины и проверяет что это все внесено в список).
Несмотря на то, что ноликов дейстивтельно не хватает - длина таки 65 (мм). Если кто таки расскажет, что обозначает этот дополнительный нолик - будет здорово.
Хотелось бы чтобы все основные части фрэймворков были бы полностью взаимозаменяемыми.
Разные фреймворки потому и появляются, что у людей разное видение на хороший API
Я тут на минуточку напомню, что FIG в PHP FIG - Framework Interop Group. И цель этой группы как раз делать интерфейсы, позволяющие делать совместимые компоненты, в частности, фреймворков. Чтобы можно было не писать, например, классы команд миграции доктрины отдельно для Yii, одельно для Symfony, Лары и тд, а написать один класс, который будет работать в любом из них, если ему через DI скормить правильные зависимости и правильно вызвать потом согласно спецификации стандарта.
На условный DI же есть стандарт. Да, есть куча разных имплементаций и конфигурируются они все по-разному. Но стандарт есть и вполне успешный как по мне. Почему не сделать такой же для консоли?
Ну, так \DateTimeImmutable тоже крякает, как мутабельный объект.
Ну это не совсем правда. У него все это более явно прописано в сигнатурах мутирующих методов. А доступ к ним есть только в том случае, если вы явно знаете, что работаете с \DateTimeImmutable. Если у вас сигнатура \DateTimeInterface, а вы пытаетесь использовать это как \DateTime, а по факту там оказался \DateTimeImmutable - то вы ССЗБ. Если у вас сигнатура \DateTime - то, \DateTimeImmutable вы туда просто не передадите.
чтоб при изменении свойства создавался новый объект
Не очень понятно, как это должно выглядеть для пользователя программиста.
$immutable = new Immutable('data');
$immutable->data = 'new data';
В какой переменной у нас окажется новый объект с измененными данными при таком вызове? + Это очень неявное поведение, больше похоже на бомбу замедленного действя. Люди будут пытаться работать с этим как с мутабельным объектом (потому что он выглядит и крякает как мутабельный объект) и это неизбежно будет приводить к фрустрации, когда они будут понимать, что в итоге оно не работает как они предполагали.
Не, тут же наоборот, не код должен знать поо схему, это как раз нормально, миграции версионируются и код знает о них, какие применены в какой версии приложения. Наоборот, с одной схемой БД работают разные версии приложения и БД при обработке запросов должна эту версию получить (через сессию или запрос) и учесть в работе констрейнта
а) какое-то голословное утверджение. а могут работать и корректно, отвечу я вам. как напишете
б) валидации, которые максимально не используют БД нагружают ее больше, чем те, которые на каждый запрос пытаются выполнить блокирующую запись, я правильно вас понял?
в) вот здесь, простите, уже начинает походить на какой-то фанатизм. проверка на обязательность поля - это одно сравнение. вы серьезно думаете что оно работает критически медленней в приложении?
Ну вот здесь категорически не соглашусь. в апп валидации можно выполнять прямо на том DTO, что вы получаете при вызове API, на конкретных его полях. Отдавать ошибки на таких полях - 0 проблем, какое поле\объект валидировали - то в ошибке и указали. Когда дело доходит до сохранения в БД - это значит что у нас уже давно нет DTO, мы работаем с некоторой entity и валидацию выполняем на ней (пусть и в БД). И даже тут повезет и мы можем смапить обратно поля ентити на поля дто, то нам все равно нужно будет для каждого такого констрейнта индивидуально писать дополнительно обработчик ошибки в коде
Т.е. во всех таких случаях вам нужно включить в условие валидации еще и кода который с ней работает.Соответственно это решает вопросы и а/б тестирования и откатов релизов и т.п.
Звучит уже слишком сложно на уровне валидации констнейнтов в БД. это получается надо где-то на уровне сессии задавать "фиче тоглы", которые должны учитываться при работе констрейнта? Я не слишком скиловый БД разработчик, поэтому я сходу даже не скажу, заработает ли это на %databasename%. Не говоря уже о том, что это начинает походить на мем про буханку.
Так работать не будет. Что в в джаве, что в ноде, что в пыхе интерпретатор\вм у вас один конкретный и (в случае пыхи) каким вы индекс файл запускаете - тем интерпретатором все и обработается, т.к. по сути все остальное - это цепочка инклудов\реквайров из него. Да, там есть обратная совместимость, но такого что вот эти файлы исполняются таким рантаймом, а такие - другим - такое я не видел ни в одной экосистеме. Такое можно сделать запуская отдельный код через экзеки, но это какие то уже странные подходы
А, я понял о чем вы. Но снова не понял. PHP вполне себе успешно запускается после распаковки из зип архива, никогда не было проблем с расширениями. достаточно положить .so файлы в правильное место (в ext). На той же убунте легко поставить несолько версий пых параллельно, после чего тот же непривилигерованный пользователь может их вызывать по типу php7, php8, php81 и тд.
Эти папки видят все пользователи, даже бесправные, это системные папки и они прописаны в PATH. можно любому пользователю прописать любой PATH.
В общем, нет никаких хардкодных путей в самой пыхе. Они могут быть в том способе установки и настройки пыхи, которым вы пользуютесь, но не в пыхе. У меня на компе пыха лежит в C:/Tools/PHP{74,80,81}, в PATH прописана 81, но при необходимости я могу рукам вызвать любую нужную мне версию (или например в шторм прописать как интерпретатор). и весь запущенный код этой пыхой работает именно с этой версией пыхи
В любом исполняемом скрипте можно лего получить полный путь до используемого интерпретатора
https://www.php.net/manual/en/reserved.constants.php
см. PHP_BINARY
Не обязательно генерировать в зависимости от внешних данных. Это могут быть зависимости от конфига, от наличия определенных пакетов в вендоре (автоматический бриджинг). Кодогенерация генерирует более оптимальные для исполнения структуры (можно почитать например про роутиниг симфони, который генерирует огромную регулярку по факту в кэш, супероптимизированную)
Я упростил, да. Тем не менее это все же расширение, я про это. Сама идея - технически опенсурсная, можно также написать свое расширение под %языкнейм% (как было например с андроид студией, насколько я помню)
https://github.com/JetBrains/intellij-community
Т.е. фактически разница в том, что к одной системе написали годное расширение, а к другой нет, и за годное хотят деняк.
upd. попробовал поставить расширение php Для idea ultimate - работает так же моментально все после индексации. Так что тезис про преконфигуренную идею работает
я поставил какой-то топовый по загрузкам экстеншен, без него это совсем не работало.но не надо забывать,что php - это на самом деле тоже расширение для idea, иными словами phpstorm - это преконфигуренная идея
Мы сейчас обсуждаем только простой полнотекстовый поиск или все таки в том числе всякие другие поисковые возможности, анализирующие содержимое, навроде поиска вызовов функций, использования элементов языка (с учетом разного рода импортов типа *) и т.д.?
vscode делает, например, поиск использования приватного свойства класса (300 строк) настолько долго, что после phpstorm я успеваю нажать еще пару раз, думая, что оно не сработало. шторм открывает юзейджи практически мгновенно
В Глобусе регулярно пользуемся Scan&Go (тебе выдают терминал, ты им сканируешь сам все что кладешь в корзину), весьма популярная штука (судя по вечно практически пустым стендам со сканерами). На кассе только оплачиваешь + проверка всякого юридически-сложного товара (например, алкоголь, если есть - попросят паспорт и заапрувят в терминале оплату) + иногда - выборочная проверка (сотрудник сканирует часть корзины и проверяет что это все внесено в список).
Интересно, в англ вики это есть, да. В русской ни слова
Несмотря на то, что ноликов дейстивтельно не хватает - длина таки 65 (мм). Если кто таки расскажет, что обозначает этот дополнительный нолик - будет здорово.
Я тут на минуточку напомню, что FIG в PHP FIG - Framework Interop Group. И цель этой группы как раз делать интерфейсы, позволяющие делать совместимые компоненты, в частности, фреймворков. Чтобы можно было не писать, например, классы команд миграции доктрины отдельно для Yii, одельно для Symfony, Лары и тд, а написать один класс, который будет работать в любом из них, если ему через DI скормить правильные зависимости и правильно вызвать потом согласно спецификации стандарта.
На условный DI же есть стандарт. Да, есть куча разных имплементаций и конфигурируются они все по-разному. Но стандарт есть и вполне успешный как по мне. Почему не сделать такой же для консоли?
Мы точно один и тот же дайджест комментируем? Я вот про это
Ну вот в статье примерно это и написано да, что возможно сделают clone with. Это решит проблему, да.
Я считаю, что работаю с тем классом, который прописан в сигнатуре, не более. Какой там написан - так с ним и работаю.
Ну это не совсем правда. У него все это более явно прописано в сигнатурах мутирующих методов. А доступ к ним есть только в том случае, если вы явно знаете, что работаете с \DateTimeImmutable. Если у вас сигнатура \DateTimeInterface, а вы пытаетесь использовать это как \DateTime, а по факту там оказался \DateTimeImmutable - то вы ССЗБ. Если у вас сигнатура \DateTime - то, \DateTimeImmutable вы туда просто не передадите.
Не очень понятно, как это должно выглядеть для
пользователяпрограммиста.В какой переменной у нас окажется новый объект с измененными данными при таком вызове? + Это очень неявное поведение, больше похоже на бомбу замедленного действя. Люди будут пытаться работать с этим как с мутабельным объектом (потому что он выглядит и крякает как мутабельный объект) и это неизбежно будет приводить к фрустрации, когда они будут понимать, что в итоге оно не работает как они предполагали.
Не, тут же наоборот, не код должен знать поо схему, это как раз нормально, миграции версионируются и код знает о них, какие применены в какой версии приложения. Наоборот, с одной схемой БД работают разные версии приложения и БД при обработке запросов должна эту версию получить (через сессию или запрос) и учесть в работе констрейнта
а) какое-то голословное утверджение. а могут работать и корректно, отвечу я вам. как напишете
б) валидации, которые максимально не используют БД нагружают ее больше, чем те, которые на каждый запрос пытаются выполнить блокирующую запись, я правильно вас понял?
в) вот здесь, простите, уже начинает походить на какой-то фанатизм. проверка на обязательность поля - это одно сравнение. вы серьезно думаете что оно работает критически медленней в приложении?
Ну вот здесь категорически не соглашусь. в апп валидации можно выполнять прямо на том DTO, что вы получаете при вызове API, на конкретных его полях. Отдавать ошибки на таких полях - 0 проблем, какое поле\объект валидировали - то в ошибке и указали. Когда дело доходит до сохранения в БД - это значит что у нас уже давно нет DTO, мы работаем с некоторой entity и валидацию выполняем на ней (пусть и в БД). И даже тут повезет и мы можем смапить обратно поля ентити на поля дто, то нам все равно нужно будет для каждого такого констрейнта индивидуально писать дополнительно обработчик ошибки в коде
Звучит уже слишком сложно на уровне валидации констнейнтов в БД. это получается надо где-то на уровне сессии задавать "фиче тоглы", которые должны учитываться при работе констрейнта? Я не слишком скиловый БД разработчик, поэтому я сходу даже не скажу, заработает ли это на %databasename%. Не говоря уже о том, что это начинает походить на мем про буханку.