Ну по факту работа нотариуса засвидетельствовать факт, что оба участника сделки согласны с тем, что "один отдал", "второй получил". Что они там передали и как - вторично. Я имел ввиду что простой распиской обычно не обходится. Ибо её как раз обжаловать можно (ну типа под угрозой писал и всё такое)
Сейчас в РФ передача денег в присутствии нотариуса обычно происходит. Или банковский перевод через оператора в банке со справкой и заверкой справки опять у нотариуса, который подтверждает передачу средств
Ну так в том и суть, что array_key_exists проверяет именно ключ.
Наличие. Но читаем внимательно - я писал что в 98% случаев мне не нужно проверять наличие ключа, мне нужно проверить что в нем вообще что-то есть более осмысленное чем null
Учитывая, что GigaIDE это Intelij IDEA CE, к которой поддержка PHP (в виде php storm или php plugin) является коммерческим продуктом, то неудивительно, что их там нет.
Да, но для чего мы проверяем существование ключа? Если у вас бизнес логика подразумеват наличие null-значения, то да, придется использовать array_key_exists. У меня (подозреваю, что не только у меня) в 99% случаешь проверка isset($a['somekey']) служит для того, чтоб выяснить есть ли там валидное не null значение, которое как-то нужно обработать.
По факту isset($a['somekey']) заменяет if(array_key_exists("nonExistentKey", $a) && !is_null($a['somekey']))
Значит он тупее, чем я думал, либо через кастом классы с apply оно работает не так (в apply взаимоисключающие свойства перекрываются последним для ЭТОГО блока, что логично)
На их месте, очевидно, что в двух данных блоках есть различия в bg-* и можно было бы сгенерить цепочки, которые работали бы правильнее
проверьте, даже интересно, я в целом могу предпололжить как сделал бы я на месте tw, но что будет у них, я хз. Подозреваю что сгенерится два класса .w-big.w-small {} .w-small.w-big {}
Понятно, что в обычном варианте они будут взаимоисключающие. Но я бы еще взял вышестоящие элементы и попробовал наследоваться от них если они разные
Я про сами шаблоны ничего не говорил, он прочитает все указанные в разделе content конфига и будет строить цепочки по тем классам, которые там указаны + входящй css c apply.
Мы сменили в одном проекте версии с 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"]}
Я, честно говоря, хз как это можно не различать и говнякать всегда {}?
Ну по факту работа нотариуса засвидетельствовать факт, что оба участника сделки согласны с тем, что "один отдал", "второй получил". Что они там передали и как - вторично. Я имел ввиду что простой распиской обычно не обходится. Ибо её как раз обжаловать можно (ну типа под угрозой писал и всё такое)
Сейчас в РФ передача денег в присутствии нотариуса обычно происходит. Или банковский перевод через оператора в банке со справкой и заверкой справки опять у нотариуса, который подтверждает передачу средств
Наличие. Но читаем внимательно - я писал что в 98% случаев мне не нужно проверять наличие ключа, мне нужно проверить что в нем вообще что-то есть более осмысленное чем null
Учитывая, что GigaIDE это Intelij IDEA CE, к которой поддержка PHP (в виде php storm или php plugin) является коммерческим продуктом, то неудивительно, что их там нет.
Да, но для чего мы проверяем существование ключа? Если у вас бизнес логика подразумеват наличие null-значения, то да, придется использовать
array_key_exists. У меня (подозреваю, что не только у меня) в 99% случаешь проверкаisset($a['somekey'])служит для того, чтоб выяснить есть ли там валидное не null значение, которое как-то нужно обработать.По факту
isset($a['somekey'])заменяетif(array_key_exists("nonExistentKey", $a) && !is_null($a['somekey']))Значит он тупее, чем я думал, либо через кастом классы с apply оно работает не так (в apply взаимоисключающие свойства перекрываются последним для ЭТОГО блока, что логично)
На их месте, очевидно, что в двух данных блоках есть различия в bg-* и можно было бы сгенерить цепочки, которые работали бы правильнее
проверьте, даже интересно, я в целом могу предпололжить как сделал бы я на месте tw, но что будет у них, я хз.
Подозреваю что сгенерится два класса
.w-big.w-small {}
.w-small.w-big {}
Понятно, что в обычном варианте они будут взаимоисключающие. Но я бы еще взял вышестоящие элементы и попробовал наследоваться от них если они разные
Я про сами шаблоны ничего не говорил, он прочитает все указанные в разделе content конфига и будет строить цепочки по тем классам, которые там указаны + входящй css c apply.
Насколько я видел код битрикса N-летней наверное давности - там всё было очень криво
Мы сменили в одном проекте версии с 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 {} надо налепить туда объект как-то так
Я, честно говоря, хз как это можно не различать и говнякать всегда {}?