Мы сменили в одном проекте версии с 5.0 до 8.3 исправив только create_function в preg_replace_callback с выходом 8.0 в паре мест на замыкание.
Все зависит от того как изначально написан php-код. В соседнем проекте так просто не было, но там и кодили его изначально очень странные персонажи (со странными решениями и любители Go в настоящее время, кхе-кхе)
Для начала задайте вопрос себе: в чем отличие ассоциативного массива от обычного с точки зрения логики, а не внутреннего устройства (которое в php, помнится, одинаковое)?
Пустой массив не является ассоциативным. И поэтому кодируется как список [], так же как и непустой и не ассоциативный.
Непустой ассоциативный кодируется как объект {}, потому что очевидно, по другому в js его не закодировать
При чем тут принимающая сторона? Писать правильный код нужно кодирующей стороне
Увы. Смысл этой ветки в том, что люди, которым требуется объект на выходе – пихают вместо него массив, а потом говорят, что php говно.
Логика вообще полезная штука. Или Вы хотите оспорить утверждение, что ['a','b'] это «непустой массив»? Вы считаете что он «пустой» или что он «не массив»?
мы с вами
Оглянулся, я тут вроде один, не надо ко мне во множественном числе обращаться :-)
От этого и синтаксис, как по мне, получается нелепый (непривычным на фоне остальных языков) - с этими вездесущими тэгами в начале файла,
Этот «нелепый» синтаксис на 80% совпадает с синтаксисом Java и C++
обязательными $ для переменных и т.п.
Ну один символ для всех переменных это не так уж и страшно, ничего такого. Поглядите в Perl, там $ для скаляров, @ для списков и % для хешей. Никто не жаловался
Речь шла про json_encode и пустые массивы. Которые действительно по умолчанию кодируются в список.
А что, непустые массивы кодируются во что-то другое? В json объекты {} кодируются по-умолчанию ассоциативныемассивы, простые же массивы (ок, они же и есть списки) кодируются как json списки [], так же как и пустые массивы (которые из за своей «пустоты» не являются ассоциативными).
Если уж бизнес логика @posledam желает получить в json именно пустой объект, то почему кто-то туда пихает массив? Где логика? Хотите пустой объект - пихайте пустой объект. А уж как его приготовить в php, через new \stdClass() или кастинг (object) [] не важно. Мне лично понятнее первое.
$a = []; // пустой массив
$b = ['m1','m2']; // не пустой массив
$c = ['k1'=>'v1','k2'=>'v2']; // не пустой ассоциативный массив
$o = new \stdClass(); // новый объект
$of = (object) []; // объект из массива через кастинг
echo json_encode(['a'=>$a,'b'=>$b,'c'=>$c,'o'=>$o,'of'=>$of],JSON_UNESCAPED_UNICODE);
Еще раз: в случае tailwind и его "атомарных" классов "компилятор" в результирующий css сам сгенерит такую последовательность, чтобы именно последний, указанный (из взаимно-исключающих атомов) в верстке, применился.
Если, конечно, вы будете "компилировать" шаблоны и директивы, а не выкатите полный набор tw как есть
Чтоб в PHP получить в json_encode {} надо налепить туда объект как-то так
// чтоб получить {} надо сговнякать объект
$a = new \stdClass();
$a->foo = 'foo';
$a->bar = 'bar';
// а "плоский" список даст []
$b = ['foo','bar'];
echo json_encode(['a'=>$a,'b'=>$b]);
{"a":{"foo":"foo","bar":"bar"},"b":["foo","bar"]}
Я, честно говоря, хз как это можно не различать и говнякать всегда {}?
Опять не работает, почему-то не может переконвертить число в строку "Fatal error: Uncaught Error: Method User::__toString() must return a string value"
И что не так? Вы же за строгую типизацию? Соверешенно очевидно, что магический __toString должен возвращать именно string, а не int или что-то ещё
Или у нас есть css (scss) и php файлы. И тут и там упоминаются одни и те же html-классы. Только вот почему-то редактор php о том, что в css написано вообще не в курсе и автоподстановка названий классов там не работает
По крайней мере PHPStorm/IntelliJ IDEA отлично умеют в рамках как минимум одного проекта видеть стили в css и автодополнять их в html/php коде. Или если css включен в этом html файле
Так для php уже много лет массивы с [] и {} - одинаковое
Оно разное, так же как и в JS. Первое массив. Второе объект.
То что json_decode в php можно (и в 90% случаев так и используется) включить associative режим, когда все JS объекты будут возвращаться как массивы - это немного другое
Никакого встроенного веб-сервера нет, его придётся написать.
Ну строго говоря встроенный web-сервер в php всеже есть. https://www.php.net/manual/ru/features.commandline.webserver.php
Но очевидное предупреждение как бы намекает
Внимание
Веб-сервер предназначен для помощи в разработке приложений. Он также может быть полезным в тестовых целях или для демонстрации приложения, запускаемого в полностью контролируемом окружении. Он не выполняет функции полноценного веб-сервера и не должен использоваться в общедоступных сетях.
а вот в случае class="first second" — применятся оба.
В случае атомарных фреймворков типа tailwind в конструкции class="w-big w-small" будет применен именно последний. Ибо переопределение свойств и есть часть CSS
Когда-то мне тоже казалось, что php-фрейворки не нужны. Ну в принципе они не особо нужны для мелких проектов с одним разработчиком и его велосипедами.
Но вот в какой-то момент мы решили немного отрефакторить тот лютый легаси монолит, что писался разными людьми в разное время в течение 15+ лет. И если один из нас двоих (не я) еще чуть понимал, что там и как работало, то мне было сильно проще и быстрее взять и переписать один из древних разделов на сайте просто с нуля на Laravel. Попутно рефакторя в него же какие-то общие фичи типа регистрация-авторизация-профили и т.п. И теперь мы можем в принципе остальное довольно быстро переписывать под Laravel тупо не разбираясь как оно там раньше работало, а просто повторяя функционал, но во многом проще, быстрее и главное – единообразнее
Мы сменили в одном проекте версии с 5.0 до 8.3 исправив только create_function в preg_replace_callback с выходом 8.0 в паре мест на замыкание.
Все зависит от того как изначально написан php-код. В соседнем проекте так просто не было, но там и кодили его изначально очень странные персонажи (со странными решениями и любители Go в настоящее время, кхе-кхе)
Еще короче
Я вам написал все варианты выше. Ассоциативные массивы кодируются как js object, индексные, включая пустые - как js array
Для начала задайте вопрос себе: в чем отличие ассоциативного массива от обычного с точки зрения логики, а не внутреннего устройства (которое в php, помнится, одинаковое)?
Пустой массив не является ассоциативным. И поэтому кодируется как список [], так же как и непустой и не ассоциативный.
Непустой ассоциативный кодируется как объект {}, потому что очевидно, по другому в js его не закодировать
При чем тут принимающая сторона? Писать правильный код нужно кодирующей стороне
В этом и смысл, остается только то, что включено в дефолтное поведение и те классы и их наборы, которые есть в файлах через
@applyили в версткеУвы. Смысл этой ветки в том, что люди, которым требуется объект на выходе – пихают вместо него массив, а потом говорят, что php говно.
Логика вообще полезная штука. Или Вы хотите оспорить утверждение, что
['a','b']это «непустой массив»? Вы считаете что он «пустой» или что он «не массив»?Оглянулся, я тут вроде один, не надо ко мне во множественном числе обращаться :-)
А что в go какие-то свой регулярки? КМК смысла сравнивать особо нет, в PHP libpcre/libpcre2 как и в 90% остального софта
Этот «нелепый» синтаксис на 80% совпадает с синтаксисом Java и C++
Ну один символ для всех переменных это не так уж и страшно, ничего такого. Поглядите в Perl, там $ для скаляров, @ для списков и % для хешей. Никто не жаловался
А что, непустые массивы кодируются во что-то другое?
В json объекты {} кодируются по-умолчанию ассоциативные массивы, простые же массивы (ок, они же и есть списки) кодируются как json списки [], так же как и пустые массивы (которые из за своей «пустоты» не являются ассоциативными).
Если уж бизнес логика @posledam желает получить в json именно пустой объект, то почему кто-то туда пихает массив? Где логика? Хотите пустой объект - пихайте пустой объект. А уж как его приготовить в php, через new \stdClass() или кастинг (object) [] не важно. Мне лично понятнее первое.
Еще раз: в случае tailwind и его "атомарных" классов "компилятор" в результирующий css сам сгенерит такую последовательность, чтобы именно последний, указанный (из взаимно-исключающих атомов) в верстке, применился.
Если, конечно, вы будете "компилировать" шаблоны и директивы, а не выкатите полный набор tw как есть
Чтоб в PHP получить в json_encode {} надо налепить туда объект как-то так
Я, честно говоря, хз как это можно не различать и говнякать всегда {}?
И что не так? Вы же за строгую типизацию? Соверешенно очевидно, что магический __toString должен возвращать именно string, а не int или что-то ещё
По крайней мере PHPStorm/IntelliJ IDEA отлично умеют в рамках как минимум одного проекта видеть стили в css и автодополнять их в html/php коде. Или если css включен в этом html файле
Оно разное, так же как и в JS. Первое массив. Второе объект.
То что json_decode в php можно (и в 90% случаев так и используется) включить associative режим, когда все JS объекты будут возвращаться как массивы - это немного другое
Ну строго говоря встроенный web-сервер в php всеже есть.
https://www.php.net/manual/ru/features.commandline.webserver.php
Но очевидное предупреждение как бы намекает
Вмысле НЕ ТЕ?
На уровне "компиляции" tailwind применит только последний в списке
В случае атомарных фреймворков типа tailwind в конструкции class="w-big w-small" будет применен именно последний. Ибо переопределение свойств и есть часть CSS
Когда-то мне тоже казалось, что php-фрейворки не нужны. Ну в принципе они не особо нужны для мелких проектов с одним разработчиком и его велосипедами.
Но вот в какой-то момент мы решили немного отрефакторить тот лютый легаси монолит, что писался разными людьми в разное время в течение 15+ лет. И если один из нас двоих (не я) еще чуть понимал, что там и как работало, то мне было сильно проще и быстрее взять и переписать один из древних разделов на сайте просто с нуля на Laravel. Попутно рефакторя в него же какие-то общие фичи типа регистрация-авторизация-профили и т.п. И теперь мы можем в принципе остальное довольно быстро переписывать под Laravel тупо не разбираясь как оно там раньше работало, а просто повторяя функционал, но во многом проще, быстрее и главное – единообразнее
Ничего, что трейты появились в PHP 5.4 аж 12 лет назад?