> Потому что у вас не DI-контейнер, а Service Locator. И это антипаттерн.
Покажите, пожалуйста, недостатки подхода, который предложил Davert, которые отсутствуют при использовании библиотеки, которую, например, предоставил Elfet.
Вот, если честно, с этим языком знаком мало. Да, не совсем тип, да, не со строками(я вообще про строки и не говорил), да, это не функция самого языка, а стандартной библиотеки и тем не менее это очень похоже именно на то о чём идёт речь.
Если я хочу найти вхождение подстроки в строку(в php считай strpos), я ожидаю, что мне вернется null,nil или -1
Не знаю. Должно быть это дело привычки. Хотя действительно, при невозможности вычислить результат можно и null возвращаеть. Но для пользователя таких конструкций положение дел не изменится. Это будет тоже, но другое специальное значение, которое надо будет так же специально проверять. «null,nil или -1» — это специальные значения.
по сути тоже самое. Только мне "-1" не нравится. Потому что это специальное значение для особых случаев, для других случаев надо будет придумывать что-то другое (как в моём примере), а это уже не общий подход.
Кстати, как выяснилось, у разработчиков PHP null может вернуться из функции, но в других обстоятельствах.
Мне кажется, что Ваше возмущение сводится к «почему в PHP некоторые вещи устроены не так как в некоторых других языках?». Взять хотя бы erlang, которые в некоторых случаях возвращает false в аналогичных ситуациях.
ммм… Кстати, да. Таким подходом я и сам пользуюсь. Но не всегда.
Получается так, что мы пользуясь этими функциями, совершаем двойную работу по поиску (или какой-то ещё обработке). Либо эти функции должны иметь какое-то общее состояние.
Я бы не стал называть приведённый кусок говнокодом. Просто дополнительная предосторожность, быть может полученная, из опыта программирования в PHP.
Если метод может вернуть хоть что-то, кроме boolean, то лучше проверить излишне строго сейчас, чем потом неуловимые искать баги. Даже, зная, что этот кусок кода возвращает массив, то лучше проверить строго, потому что пустой массив жуглиться в ложь. Конечно, трудно представить, чтобы в результате запроса можно получить набор пустых массивов, но…
Так же я заметил, что документация по указанной Вами ссылки не соответствует действительности. Этот метод возвращает результат метода PDOStatement::fetch, который в свою очередь может такого навозвращать, что лучше написать строго и знать, что при любом раскладе эта строка кода работать будет одинаково, чем разбираться с каждым способом перебора значений и что там может сконвертироваться в ложь.
Что же касается вопроса «так, не так», так это вопрос спорный. Мне уже трудно об этом судить — я привык. Но хочу чтобы Вы предложили лучший вариант в таких случаях.
Допустим есть координатный отрезок [-64,64] и точка, которая не принадлежит этому отрезку (и даже прямой, на которой лежит этот отрезок). Что должна вернуть функция getPoint(), в таком случае?
Symfony — это имя вендора. Можете не использовать свой ник. Можете взять любое название, под которым будете выпускать свои пакеты.
Поясните, пожалуйста, позитивное влияние регистрации программы?
Покажите, пожалуйста, недостатки подхода, который предложил Davert, которые отсутствуют при использовании библиотеки, которую, например, предоставил Elfet.
keysearch(Key, N, TupleList) -> {value, Tuple} | false
Не знаю. Должно быть это дело привычки. Хотя действительно, при невозможности вычислить результат можно и null возвращаеть. Но для пользователя таких конструкций положение дел не изменится. Это будет тоже, но другое специальное значение, которое надо будет так же специально проверять. «null,nil или -1» — это специальные значения.
Получим что-то типа этого:
по сути тоже самое. Только мне "-1" не нравится. Потому что это специальное значение для особых случаев, для других случаев надо будет придумывать что-то другое (как в моём примере), а это уже не общий подход.
Кстати, как выяснилось, у разработчиков PHP null может вернуться из функции, но в других обстоятельствах.
Мне кажется, что Ваше возмущение сводится к «почему в PHP некоторые вещи устроены не так как в некоторых других языках?». Взять хотя бы erlang, которые в некоторых случаях возвращает false в аналогичных ситуациях.
Получается так, что мы пользуясь этими функциями, совершаем двойную работу по поиску (или какой-то ещё обработке). Либо эти функции должны иметь какое-то общее состояние.
Так же модифицируется и работа с интерфейсом.
Вместо
получим что-то типа:
Что делает общение с интерфейсом многословнее. Но тут уже дело вкуса.
Хотя можно было бы сделать и так
И так тоже многословнее.
Если метод может вернуть хоть что-то, кроме boolean, то лучше проверить излишне строго сейчас, чем потом неуловимые искать баги. Даже, зная, что этот кусок кода возвращает массив, то лучше проверить строго, потому что пустой массив жуглиться в ложь. Конечно, трудно представить, чтобы в результате запроса можно получить набор пустых массивов, но…
Так же я заметил, что документация по указанной Вами ссылки не соответствует действительности. Этот метод возвращает результат метода PDOStatement::fetch, который в свою очередь может такого навозвращать, что лучше написать строго и знать, что при любом раскладе эта строка кода работать будет одинаково, чем разбираться с каждым способом перебора значений и что там может сконвертироваться в ложь.
Что же касается вопроса «так, не так», так это вопрос спорный. Мне уже трудно об этом судить — я привык. Но хочу чтобы Вы предложили лучший вариант в таких случаях.
Допустим есть координатный отрезок [-64,64] и точка, которая не принадлежит этому отрезку (и даже прямой, на которой лежит этот отрезок). Что должна вернуть функция getPoint(), в таком случае?