Лучший способ проверить наличие переменной в PHP; isset () явно не работает

Вы не можете проверить - но зачем вам это нужно?

Да, был бы полезен хороший пример того, почему вам это действительно нужно.

Я согласен. Насколько вам нужно знать, ни один из них не установлен, потому что оба они равны нулю. Вы не можете использовать их ни для чего.

NULL имеет очень специфическое значение в PHP, и это совершенно отдельная концепция от того, установлена ​​ли переменная или нет.

Интересное наблюдение, я этого не знал. Ответ был найден, так что это избыточно и неверно, но я бы, вероятно, использовал значение-заполнитель или объект для каждой строки, чтобы сделать поиск неустановленного свойства более понятным.

Та же проблема здесь для того же использования (значения db null). Необходимость использовать array_key_exists() не интуитивно понятна. Еще одна капля в мою чашку PHP ...

Я не вижу вариантов использования в отредактированном вопросе или каких-либо ответах и ​​их комментариях, которые фактически оправдывают наличие Переменная, который может существовать или не существовать во время выполнения. Ключи массива и свойства объекта можно рассматривать как переменные и тестировать с помощью isset, но их существование также можно проверить с помощью array_key_exists() и property_exists(), поэтому варианты использования с их участием следует рассматривать отдельно.

Register_globals приводит к глобальным переменным, которые могут существовать или не существовать во время выполнения, особенно в устаревших установках.

@chazomaticus Во-первых, если они NULL, это все равно не имеет значения. Во-вторых, если это так, мы можем списать это на одну из многих ошибок, которые были неправильными в этой функции, которая была полностью удалена из PHP. Обоснование одной плохой идеи другой не убеждает меня в разумном использовании несуществующих переменных.

Да, он был удален из новых версий PHP. К сожалению, это происходит не при каждом развертывании PHP. Кроме того, кажется бессмысленной семантической деталью спорить о том, говорим ли мы об элементах массива или переменных. Независимо от того, каких стандартов, по вашему мнению, должен придерживаться код, полезно знать, как обойти несогласованность в языке PHP.

@chazomaticus Но переменные и элементы массива принципиально разные вещи; просто потому, что вы можете делать с ними то же самое, не означает, что они на 100% взаимозаменяемы. Здесь нет «несоответствия в языке PHP», просто то, что вам случайно не нравится / не понятно. Что касается register_globals, я все еще не могу придумать ситуацию, когда даже это потребовало бы такого различия, поскольку все, что зарегистрировано из HTTP-запроса, всегда будет строкой, а не null.

Настоящая проблема здесь в том, что API баз данных PHP обрабатывают database-NULL эквивалентно PHP-NULL, несмотря на то, что это разные вещи. (PHP-NULL "не инициализирован"; database-NULL "инициализирован как пустой")

Он получил документы по этой ссылке. Прочтите первое предложение, второй абзац раздела описания по предоставленной вами ссылке. Это именно то, что он процитировал выше.

Это неплохая практика для простых скриптов, но в сложных (например, больших OO) проектах это становится невозможным. Кроме того, как я сказал выше, is_null () возвращает TRUE для переменных, которые не установлены, поэтому на самом деле нет причин делать то, что вы говорите, кроме как избежать предупреждения PHP.

Почему это может быть проблемой для хорошо спроектированных «больших объектно-ориентированных» проектов? Зачем вам вообще $ foo в теле метода, который, возможно, не был установлен до его первого использования?

Ага! СЕЙЧАС ты говоришь! Как бы вы это сделали, скажем, со свойствами класса?

В качестве варианта, если проверка должна работать и для переменных локальной области видимости, on может выполнить $defined_vars = get_defined_vars();, а затем протестировать через array_key_exists('v', $defined_vars);.

Мне это кажется немного уродливым, но в случае, когда вы фактически проверяете элемент массива, это имеет гораздо больший смысл: isset($foo[$bar]) становится array_key_exists($bar, $foo)

@alexw Переменные, "созданные" через __get, действительно не существуют. __get - это произвольный код, используемый как резерв для несуществующих переменных, который может возвращать все, что захочет, независимо от того, были ли когда-либо сохранены какие-либо соответствующие данные.

Если у вас есть волшебный метод __get, вы, вероятно, захотите также иметь волшебный метод __isset, который вы могли бы использовать.

Это, вероятно, не имеет отношения к реальности, но ... get_defined_vars() + array_key_exists БУДЕТ НЕТ проверять, действительно ли переменная была объявлен или нет, это просто способ определить, что переменная была "инициализирована" с помощью null ... Просто простое объявление - $a; - допустимый код, хотя этот метод приведет к false :) Но, как я уже сказал, это скорее "забавный факт", который может коснуться нескольких случайных людей C :-)

Я не уверен, что вы имеете в виду. Если у вас есть массив с одним элементом 'a', вам не нужно unset () element 'b', чтобы элемент 'b' не существовал в PHP, он просто не существует. То же самое, например, с глобальные переменные, которые можно рассматривать как элементы массива $ GLOBALS.

Но я согласен с тем, что переменная со значением NULL действительно существует.

PHP этого не делает, но я бы не сказал, что наиболее на других языках нет. Практически любой язык, в котором объявляются переменные, выдаст ошибку, если переменная не была объявлена, но вы можете установить для них значение NULL. Семантически NULL должно означать «нет ресурса», но отсутствие определения переменной является ошибкой программиста.

@MMiller Конечно, но писать код, который следует по одному пути в случае «отсутствия ресурса» и по другому пути в случае «ошибки программиста», довольно бессмысленно. Если вы хотите обнаружить необъявленные переменные во время отладки, используйте инструмент статического анализа, как если бы вы находили потенциальные ошибки на любом языке.

@MMiller, Круто, как ты вообще об этом подумал.

Теперь, когда я использую JavaScript, я смотрю на это немного по-другому, потому что состояний больше. Если вы скажете alert(x);, когда x никогда не объявлялся, будет выдана справочная ошибка. Если вы сделаете var x; alert(x);, вы получите undefined. undefined - это состояние, отличное от null. Например, многие программы используют хэш параметров, например варианты сценария лайтбокса могут быть такими: var options = { onClose: function () { ... }, centerHorizontally: true }. Если для onClose задано значение null, это может означать, что ничего не делать, тогда как undefined (или отсутствие) подразумевает использование настройки по умолчанию.

@MMiller Как и многие примеры здесь, ваш пример параметров JS является ключом в каком-то конкретном объекте / хэше, а не простой переменной. Таким образом, эквивалентный код в PHP будет использовать array_key_exists или property_exists, а не isset.

@IMSoP Да, я знаю. Этот комментарий был просто ответом на ответ, чтобы указать, что есть цель иметь случай, когда что-то не существует, а не когда оно равно нулю. Я не намеревался сделать свой комментарий ответом на вопрос ОП, а скорее опровержением этого конкретного ответа.

@MMiller Но это не работает как опровержение, потому что утверждение в ответе явно говорит о том, что "переменная не существует", а ваш контрпример касается свойство объекта / хэш-ключ не существует. Различие между этими случаями не случайно.

Ага, ты права, моя ошибка. Хотя то же самое было бы, если бы я сделал var onClose = options.onClose; if (onClose === undefined) { ... } else if (onClose === null) { ... }

@MMiller - это действительно лучший пример. Тем не менее, после более чем 20 лет программирования на строгих языках, ситуации, когда мне нужно было различать undefined и null, настолько редки, что я не упускаю их. ИМХО, основное применение undefined - «ошибка программиста на нестрогом языке». Строго говоря, если мне нужно отдельное состояние для client did not state a value, я объявляю значение, соответствующее ситуации, и проверяю его. В худшем случае придется добавить отдельную флаговую переменную. Но выполнение этого редко лучше, чем необходимость ВСЕГДА справляться с ДВУМЯ разными состояниями, не имеющими значения !!

Отличный ответ. Я столько раз вижу, как люди разглагольствуют о том, как они ненавидят ту или иную особенность языка. Но они, кажется, предполагают, что «если это не МОЙ путь, значит, он сломан». Да, есть плохие дизайнерские решения. Но есть и очень близкие по духу разработчики!

Есть ОГРОМНАЯ разница между неустановленной переменной и переменной === null. Один не существует, другой имеет значение null. Аргументы, что null означает отсутствие значения, просто неверны. Null - это ЗНАЧЕНИЕ типа null. Это совершенно допустимое значение, и у php нет причин рассматривать его как несуществующее значение, что, к сожалению, и делает. Было бы нормально, если бы несуществующие переменные были нулевыми, а каждая существующая переменная не была бы нулевой, и присвоение null переменной отключило бы ее. Но есть МНОГО ситуаций, когда функции возвращают null как фактическое значение. Тогда мы облажались, потому что нет кровавого способа проверить это.

@enrey Если функция возвращает NULL, и вы тестируете это возвращаемое значение, значит, вы его куда-то поместили, поэтому знать указывает, что контейнер существует. За исключением отладки, никогда не должно быть случая, когда переменная - в отличие от ключа массива или свойства объекта - «могла или не могла быть еще установлена».

@IMSoP, что привело вас к этой идее? Разве вы никогда не сталкивались с ситуацией, когда функция находится в середине сложных циклов и условий, и она могла или не могла быть запущена, а возвращаемое значение было / не было присвоено переменной, и тестирование переменной Существование - единственное, что может вам помочь ... Ну, не совсем так, поскольку вы не можете проверить установленную / неустановленную переменную в php, вам пришлось добавить этот $my_function_has_run = true; прямо рядом с вызовом вашей функции. Что ж, это не делает язык менее полным по Тьюрингу. Но это, безусловно, делает его более раздражающим.

@enrey Для меня это очень похоже на отладку. Если эта проверка необходима в окончательном коде, у вас есть довольно дурацкая логика. Помните, что во многих языках переменная либо существует, либо не основана на объявлении в определенной области, поэтому такой тест будет бессмысленным.

@IMSoP true, но php не следует логике других языков. У него есть свой мир, и в этом собственном мире переменная создается при назначении, для нее нет объявления. Кроме того, даже на других языках вы можете проверить наличие переменной. Я не говорю, что равенство null переменной unset - это большая проблема, это всего лишь небольшая проблема в языке, который был построен исключительно из небольших неприятностей. Итак, что угодно. Вернемся к делу.

@enrey См. мой ответ, почему неинициализированная переменная все еще может считаться "существующей". Вы даже можете назначить из него другую переменную, и вы получите null. Было бы гораздо неприятнее иметь вторую константу, представляющую не-нулевую-но-читаемую-из-унитализованной-переменной, что было бы последовательным результатом того, что isset() проводит такое различие.

Я знаю, что мы «не должны» проверять существование переменных в php, черт возьми, нет даже реального способа это проверить. Я не собираюсь писать код, зависящий от него, потому что это невозможно в php. Это ограничение php. Очевидно, что существует разница между ненулевой и ненулевой переменными, но php не позволяет их различать. Тем не менее, многие мета-функции зависят от него внутри: чтение несуществующей переменной var вызывает уведомление, isset($a['x']) сообщит вам false, если x равен нулю, но он будет отображаться в count($a) .. compact будет работать со всеми установленными переменными, включая nulls, и так на.

@enrey Осторожно, еще раз в некоторых ваших примерах используются массивы, для которых у нас есть array_key_exists. Подавляющее большинство функций обрабатывает неинициализированную переменную как равную нулю, поэтому совершенно разумно не различать эти два состояния. Уведомление - это намек на то, что вам следует изменить свой код, чтобы явно инициализировать его для лучшего кода, а не потому, что он имеет какое-либо значение само по себе. Что касается compact, это больше похоже на отражение кода, чем на то, что вы видите в повседневном коде.

Этот ответ ошибочен в одном из основных моментов: в объектно-ориентированном программировании значение null является логическим выбором для обозначения «без объекта». Например, в исключительных обстоятельствах, когда функция может возвращать объект или не возвращать объект, очевидным выбором будет null. Технически в PHP можно использовать false или любое другое значение, которое считается ложным в логическом контексте, но тогда вы теряете некоторую семантическую чистоту. Таким образом, null - это вполне разумное значение для инициализации переменной, которая в конечном итоге должна содержать объект, потому что является имеет отношение к тому, чем она должна стать.

IMSoP, Руководство по PHP фактически дает понять, что неинициализированные переменные могут иметь любое количество типов, в зависимости от контекста, поэтому неправильно говорить «подавляющее большинство функциональных возможностей ...», не зная, что делает код. Кроме того, никто не утверждает, что вы инициализируете переменные не должен перед их использованием. Вопрос просто в том, как это решить, учитывая ситуацию, когда существует некоторая двусмысленность в отношении того, была ли объявлена ​​переменная.

@IMSoP key состоит из 3 символов, isset - из 5 символов, array_key_exists - из 16. Подумайте об этом. Плюс array_key_exists жалуется, если самого массива не существует. Поэтому правильная проверка индекса, который находится внизу огромной древовидной структуры, приведет к появлению большого количества шаблонов, и все это только для проверки существования одного ключа. Опять же, я не говорю, что это непригодно, это просто причиняет ненужную боль. Но мне все равно, я все равно убегаю от php.

@chazomaticus 1) Я никогда не говорил, что null недопустимы; Я сказал, что не существует допустимого использования для «неинициализированный» в качестве значения / состояния, отличного от null. 2) Я раньше не видел этого описания неинициализированных переменных, но обратите внимание, что на практике они постоянно ведут себя так же, как и значение null, принудительное в той же ситуации. Я поддерживаю утверждение, что, за исключением очень эзотерических ситуаций, нет и не должно быть значимого различия между двумя состояниями.

@enrey Я не совсем уверен, какое отношение имеет длина имен функций ко всему, что здесь обсуждается. Аргумент для рекурсивного array_key_exists (то есть того, который выполняет несколько проверок существования, а не проверяет нормальную переменную по конкретному тесту) является интересным; Я думаю, вы можете использовать @ «оператор заткнись», но это всегда похоже на взлом. Однако это все еще не вариант использования функции, которая обнаруживает неинициализированные голые переменные, а не ключи массива.

IMSoP, я думаю, вы запутались. Мой комментарий о null был ответом на этот ответ, а не вы. И повторюсь по поводу вашего утверждения: этого никто не отрицает! Этот разговор вышел далеко за рамки полезного.

@chazomaticus Извините, я неправильно понял этот момент. Это правильное пояснение к ответу, что null может быть допустимым состоянием инициализации. Конечно, тогда это будет константа в коде, поэтому нет необходимости проверять, произошло это или нет во время выполнения.

NULL идеально подходит для установки произвольных переменных, если значение еще не определено. Таким образом, аргумент против установки $ var как NULL нарушен. Так ISSET ()

Этот ответ в корне ошибочен, как показали Энри и другие.

Пока PHP выдает ошибки для неопределенных переменных, но не для null, тогда есть разница. Если null и undefined на самом деле являются одной и той же концепцией, тогда PHP должен принимать значения по умолчанию undefined / undeclared как null и никогда не выдавать ошибку, но никто этого не хочет, потому что это кошмар разработки. Null и undefined могут не отличаться в контексте семантики значений, но они очень разные, когда дело доходит до написания понятного и отлаживаемого кода.

@ChrisMiddleton Совершенно верно! В большинстве языков существует большая разница между null / nil и undefined. Первый - это тип данных, то есть вы можете назначать его переменным (в основном это означает «пустая, но не пустая строка, ноль или ложь»). Последнее является ключевым словом только для чтения, которое принимает значение true в случае, если идентификатор не найден. Разница в том, почему в JavaScript есть два разных ключевых слова, и почему более строгие языки, такие как Basic, не позволяют вам устанавливать для Integer / Booleans / Strings значение Null (только для вариантов или объектов).

Есть множество причин, по которым переменные должны иметь значение NULL. Что, если я получаю данные из базы данных и хочу проверить, существует ли столбец, но имеет ли он значение NULL (что происходит постоянно)?

@HugoZink - ИМХО, вы неправильно поняли обсуждение. Никто не предлагал, чтобы переменные не были равны нулю. Вопрос только в том, нужны ли и когда должны быть ДВЕ разные концепции: null и has never been set to anything, not even to null. Этот пространный ответ призван продемонстрировать, что, когда вам нужно сделать это различие, существует способ некоторый сделать это в php [за исключением ограниченных случаев, когда есть разногласия о том, насколько они важны]. Хотя необходимый код различается в зависимости от того, какой объект вы исследуете.

В вашем примере проверяется не наличие переменной, а ключ массива. Решение этой проблемы существует в виде array_key_exists. Вы никогда не должны оказаться в ситуации, когда во время выполнения вы не знаете, существует ли реальная переменная.

@chazomaticus Что ж, вы никогда не должны попадать в ситуацию, когда register_globals включен, поэтому я поддерживаю это утверждение.

О, я согласен. Тем не менее, не все могут контролировать, где развертывается их код. Полезно иметь информацию для каждой ситуации, независимо от того, как все должно быть или нет.

@chazomaticus Если ваша проблема - register_globals, то ваш ответ - не изменение isset(). Руководство по PHP упоминает, что «в целом хорошая практика программирования - сначала инициализировать переменные», что решает проблему register_globals во время разработки, а не во время выполнения. Также существует запись в FAQ, дающий функцию unregister_globals() для работы с ней во время выполнения.

Очень хорошие моменты, хотя и не совсем ответ на вопрос.

На явный вопрос «Как мы должны надежно проверять наличие переменной в PHP?» Я отвечаю: «Нет, и вот почему». И этот ответ, и greatbigmassive также отвечают на вопрос скрытый «Почему isset() так себя ведет?».

«Если вы читаете переменную, в которой в данный момент нет записи, PHP считает, что эта переменная имеет значение NULL». Это неправда. Неопределенная переменная просто не определена. Он может вернуть null, когда вы попытаетесь получить к нему доступ, но это не имеет значения.

@HugoZink К чему это не имеет отношения? Любой тест, который вы сделаете для значение неопределенной переменной, скажет вам, что это значение null. Существует ли это значение до того, как вы посмотрите на него, - это вопрос философов, но с точки зрения любого наблюдаемого поведения значение неизменно является null.

Возможно, это выходит за рамки этого вопроса, но вы можете добавить "0" в таблицу для полноты и ясности работы empty.

Если намерение состоит в том, чтобы избежать предупреждения о том, что ваши переменные не были объявлены, решение состоит в том, чтобы исправить ваш код, чтобы правильно объявить их. Ваша функция inst в основном похожа на оператор подавления ошибок @: «Я знаю, что делаю здесь что-то не так, но я просто хочу, чтобы это сообщение исчезло, фактически не изменяя работу моего кода каким-либо образом».

С другой стороны, методы обнаружения гениальны, но я по-прежнему твердо убежден в том, что вы никогда не должны использовать их, кроме как для отражения тех самых предупреждающих сообщений, которые они улавливают. (Вероятно, вам следует уточнить, что ваша версия буферизации вывода требует, чтобы error_reporting был установлен на высокий уровень, а display_errors был включен.)

Предупреждение о неопределенных переменных - это подсказка программисту, что они сделали что-то не так в коде. Вне отладки (для которой существуют инструменты за пределами языка) никогда не должно быть необходимости в программе для обнаружения такого состояния, потому что программист всегда должен знать, какие переменные они объявляют.

Я думаю, что это то, что многие говорили раньше, или я ошибаюсь?