Каламбур на PHP

[leviathan]

а что, в определенных ситуациях вполне применимо и работоспособно.

[coylOne]

никто и не спорит. Просто это каламбур на php

[leviathan]

Я к тому, что каламбур-то рабочий :) У меня в коде такое же пару раз проскакивало.

[coylOne]

Ну ясно рабочий. Эт мой код. Вчера написал, а сегодня разглядел =)

[twistr]

Таких ситуаций быть не должно. Если переменная изначально задумывалась как массив, то она должна им быть.

[leviathan]

Входная переменная функции, функция принимает строку либо массив. Код функции обрабатывает переменную в любом случае как массив, а этот кусок превращает строку в массив с одним элементом.

[ptalus]

так twistr об этом и говорил :-)
Такой прием — хороший пример багописания.

[coylOne]

в каком смысле?

[ptalus]

функция проектировалась для работы с одним типом данных, а используется с другим. Хотя как каламбур, мне это понравилось

[coylOne]

дело в том, что функция спроектирована для работы с массивом, по этому надо обезопасить её от получения «немассива». Вот для этого и используется этот «антикреш каламбур» =)

[ptalus]

Почему она получает «немассив»? Из-за бага в месте вызова? То, что вы описали называется «костыль»

[coylOne]

Нет не из-за бага в месте вызова, а из-за того, что злоумышленник с удалённого сервера передал нарочно не массив, а скаляр (например, в ответ на какой-нибудь запрос).

Ну если это костыль, но проверка переменных перед внедрением их в SQL-запрос — тоже костыль. И проверка, не передали ли нам число больше по разрядности, чем мы можем принять — тоже костыль. Ну и наконец авторизация на сайте (читай, проверка правильности юзера) — тоже костыль.

[ptalus]

Может быть лучше сделать экзепшн или вернуть код ошибки, в данном случае?
А как функции определить баг это или злоумышленник :-)
Допустим это баг, то она вернет «неожиданный» результат, который в следующей функции опять будет «откалабурен» и т.д. В конце концов это приведет к какому нибудь неправильному результату, например к пустой странице или warning совсем в другом месте. Вы как, программист поддерживающий систему начнете искать причину ошибки и вам придется раскрутить всю эту цепочку вызовов обратно, хотя если бы ваша функция изначально сигнализировала об ошибке, то найте место ее появления было бы гораздо проще
Т.е. данных подход («каламбур») отдаляет место появления бага от места его обнаружения, что вобщем то плохо :-)

[coylOne]

Не согласен. Дело в том, что [в данных условиях задачи] «каламбур» этот делает преобразование достаточное для того, чтобы функция нормально работала. А функция уже вернёт правильный, однозначный результат.

Вы неверно понимаете мою мысль — она заключается в том, что серверная часть должна возвращать предсказуемые результаты, а вот клиентская не обязана. Пример со злоумышленником просто хрестоматийный, а это может быть и недоработка программиста клиентской части, и сбой в оборудовании, но факт остаётся фактом — извне может придти всё что угодно и скрипт обязан проверить правильность ввода. Он не должен (хотя можно и попробовать) пытаться определить злоумышленник это или нет. Он должен обработать поступившие данные и привести их к нужному виду. Если не получится — тогда уже генерить эксепшн и дальше по списку.
После такой обработки функция должна вернуть предсказуемый результат (и она его возвращает). После этого никакой «цепочки» не будет.

Если на каждый чих пользователя вы будете генерить ошибки и посылать его — он не станет пользоваться вашим сервисом. Именно по этому яндекс распознаёт опечатки (опять-таки хрестоматийный пример) и транслит.

[coylOne]

И вообще все ваши доводы порочат не сам «каламбур», а то, что является предметом холиваров по всему инету — динамическую типизацию в php.
Я, конечно, не собираюсь вступать в очередной холивар, но считаю, что это плюс для языка, ориентированного на web.

[coylOne]

и еще раз ссылочка на тему str_replace
почитайте внимательно =)

[coylOne]

и до кучи.
обозначение mixed

[p0is0n]

если нужно только это, то можно так:

function test(array $array) {}

[coylOne]

Можно, но это приведёт к фатальной ошибке и аварийном завершению скрипта, а это не гибко. Конечно, в некоторых случаях — надо делать именно так, но язык позволяет более гибко обойти эту ситуацию.

[p0is0n]

Сейчас потестировал два варианта:

1.

if (! is_array($array))
{
	$array = array($array);
}

2.

$array = (array) $array;

второй намного быстрей)

[coylOne]

ахаххахаха =))) Это плюс!

[david_mz]

Функция может проектироваться и для работы не с одним типом данных. В нормальных языках это называется «перегрузка функций». Вполне рабочий приём.

[leviathan]

Почему? Если функция универсальна и используется в разном контексте в разных частях проэкта, и иногда нужно передавать ей одну строку, а иногда удобно передать сразу несколько — чем такой подход плох?

[ptalus]

имхо, такой под написания кода неоднозначен. Строгость в определении параметров функций — это сродни применению отступов, нормальных имен переменных, комментариев — т.е. то что называют хорошим стилем.

[p0is0n]

например функция str_replace()

[leviathan]

Не совсем с Вами согласен. Если возможности кода хорошо документированы для других разработчиков, то почему не упростить использование функции в новом коде? Например, у меня есть несколько классов, constructor-ы которых принимают либо ID объекта в БД, либо уже взятый array данных из той же БД, либо другой критерий выборки для запроса в две переменных ($input и $type, $type по дефолту выставлен на ID). За счет такой универсальности эти классы очень удобно использовать.

[coylOne]

Так в том-то и дело, что этот код и добавляет, как вы говорите, «строгость в определении параметров». Он не даёт пользователю использовать метод не так как следует.

[MTonly]

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

[coylOne]

это верно, хотя и никак не влияет на код каламбура =)

[twistr]

Тогда не надо называть ее $array, а придумать другое название. А то посмотришь на аргументы функции и даже не подумаешь, что оказывается можно и строку передать.

[leviathan]

Ах, вы об этом. Да, действительно, читабельность кода может ухудшить (у меня она называлась $input). Но проблем в работе создавать не должно.

[coylOne]

а её и нельзя передавать, но защиту от дурака предусмотреть нужно.

[twistr]

Это напомнило мне цитату с баша :-)

serg> Читаю код доставшийся от коллеги
serg>…
if ($flag == false) {
# на вский случай
if (false == true)
exit;
include «execute.php»;
}
serg> чувак убил мой моск…
serg> какой нах ВСЯКИЙ СЛУЧАЙ???

[coylOne]

Ну тут все не так прозрачно. Извне могут придти любые данные. В общем всё там оправданно. В любом случае проверку на массив проводить надо. Это если бы был скрипт, который работает с БД и из неё получает данные — тогда да, можно говорить об определённости представления данных, но в моём случае это не так

[twistr]

Да все в порядке с Вашим кодом, я просто говорю, что не надо было называть переменную $array, если мы на самом деле не знаем какой у нее будет тип.

[coylOne]

Тут тоже не соглашусь:
1. Если такая переменная находится в объявлении функции, например function f($array), то это указывает программисту, что надо передать массив. Но пхп изначаль не срого типизирован и может произойти исключительная ситуация, которую надо мягко исправить. Что и делает этот код.
2. Если бы я назвал переменную иначе — калабура бы не было =)

[Nc_Soft]

на это вспоминается другая цитата

<******> к вопросу о вчерашних скриптостраданиях. Только что кодер знакомый прислал, нашёл в коде программы, написанной уволенным коллегой незадолго до ухода:
<******> #define TRUE FALSE //счастливой отладки суки
* ****** такого извращённого юмора ещё не встречал
Статья:
bash.org.ru/quote/268036

[coylOne]

Не бывает «ситуаций, которых не должно быть». Особенно в вебе. Так что все параметры надо проверять.

[porqz]

За это я и люблю PHP! ;)

[Silverstorm]

все нормально, вот давеча сам такую слабал. конечно можно было сразу по-правильному. Суть вобщем такова что некий вебсирвис по soap бросает эксепшены. Когда обектом, когда массивом, когда массивом объектов. Я заебался ловить уже все возможности и решил просто превращать все в массив.

[FeoOne]

Тоже каламбур:
if(!$bool) $bool = !$bool;

[gopline]

равносильно $bool = true;

[chEbba]

Вполне нормальная ситуевина, например, в Зендовских билиотеках такое не раз можно увидеть.

[miros]

Это кажется необычным или неправильным только тем, кто привык программировать на языках со строгой типизацией. В языках с динамической типизацией немного различное поведение функции в зависимости от типа переданного параметра это обычное дело. Такое можно часто встретить и в Zend Framework на php и в javascript (функция $ в jquery), и даже в ядре ruby (функции меняют своё поведение при передачи им опционального раби блока) Конечно, это усложняет саму функцию (некрасивой логикой) и снижает очевидность её интерфейса. Но если это даёт значительное удобство для клиентского кода, то вполне можно осторожно применять. К тому же, в таких случаях возможные входные параметры часто имеют одинаковое смысловое значение: например, можно передать или сам объект или его идентификатор.

[Silverstorm]

и это кстати офигенно удобная штука когда метод может принимать параметром различные типы данных.

[Bygaga]

Ну я думаю каламбуром это можно назвать только из за того, что не видно полного текста и непонятно для чего автор его использовал…
Вот уже массу вариантов придумали ;)

[coylOne]

о господи. заминусовали всего нафиг =)
Это же топик добра! =)

[anatoly_rr]

Сначала раздаются плюсы, и как результат топик становится топиком добра.
А наоборот не получается.

[azizoid]

то что Вы написали это НЕ каламбур!
каламбур это:
$a=1;
while($a){
$a++;
}

вот это я назвал бы каламбур.
и перестаньте засорять эфир.
PS. ничего личного

[coylOne]

неа. ваш пример — это не калабур, а бесконечный цикл =))))) \ехидный смайл\

[MrButek]

settype($array, "array");

[mayhem]

назвал бы переменную $maybeArray :)

[coylOne]

лол =)