Почему сигнатуры функций PHP настолько противоречивы? [закрыто]


17

Я просматривал некоторые функции PHP и не мог не заметить следующее:

<?php
function foo(&$var) { }

foo($a); // $a is "created" and assigned to null

$b = array();
foo($b['b']);
var_dump(array_key_exists('b', $b)); // bool(true)

$c = new StdClass;
foo($c->d);
var_dump(property_exists($c, 'd')); // bool(true)
?>

Обратите внимание на array_key_exists()и property_exists()функцию. В первом случае имя свойства (ключ для массива) является первым параметром, а во втором - вторым параметром. Интуитивно можно ожидать, что они будут иметь аналогичную подпись. Это может привести к путанице, и время разработки может быть потрачено впустую, делая исправления такого типа.

Разве PHP или какой-либо другой язык не должны учитывать согласованность сигнатур связанных функций?


2
+1 браво, это одна из первых вещей, которые я заметил в php и всегда находил раздражающим
Кевин

Мех. Используйте IDE.
Бен Дюбюссон,

Ответы:


10

То, что вы предлагаете, - это существенное изменение подписей многих существующих функций. Подумайте на минуту, как это повлияет на существующий код. Теперь предположим, что группа PHP выпустила версию PHP N, которая изменяет подписи 30% функций. Теперь представьте, что вам нужно написать код, который будет работать как на PHP vN, так и на PHP v. {N-1} - насколько это будет весело?

Теперь представьте, что вы хостер или менеджер корпоративного центра обработки данных - какой стимул у вас будет для поддержки PHP vN, при условии, что после переключения весь код будет взломан, и пользователи придут в ваш офис с вилами и факелами?


4
+1 Трудно, когда вы начали что-то неправильно, но иметь такую ​​большую базу пользователей, использующую это в своем текущем состоянии.
Энди Флеминг

4
Неплохо подмечено. Я на самом деле знал об этом, но мое главное - они должны были знать об этом в первую очередь.
Шамим Хафиз

7
@Shamim True, что является частью того, почему у PHP плохая репутация в первую очередь;)
Энди Флеминг

1
PHP, как и многие другие вещи, начинал как маленький инструмент для решения крошечной проблемы, если бы он спроектировал его «должным образом», тогда он мог бы быть лучше, но, возможно, не достиг бы тяги, поэтому никто бы не использовал его ... и другой маленький инструмент "выиграл бы", инструмент с различными несоответствиями ...
Йоханнес

3
Вот почему существует такая вещь, как амортизация. Вы создаете новые стандартизированные имена и осуждаете старый «салат-бар» имен функций, но оставляете их на несколько выпусков. В какой-то момент, когда вы получили широкую огласку, вы выпускаете новую версию основной версии, которая избавляет от них. Вот как это делается. Это чистая трусость со стороны разработчиков PHP, что они этого не сделали. Они преодолевают низкий барьер для входа, который дает PHP преимущество над другими веб-языками, и благодаря этому они успешны, поэтому им НЕ ДОЛЖНО продолжать улучшать основной язык.
Дэн Рэй

10

Потому что PHP это язык без каких-либо спецификаций.

И буквально каждый мог добавить пару функций, и в начале не было вопроса о последовательности. ТАК, беспорядок.


не каждый может добавлять функции
StasM

@StasM: Кто может, группа разработчиков? Любая ссылка, где я могу найти, как работает эта группа?
Шамим Хафиз

@StasM: хорошо, я немного преувеличил. реальная проблема заключается в отсутствии соглашений с самого начала или одного человека, ответственного за целостность кода. Сейчас уже поздно. Я сомневаюсь, что это можно изменить без буквального разветвления PHP как другого языка.
ts01

Принципы работы @Shamim Dev group - два: консенсус и доверие. Что круто, но я боюсь, что этого недостаточно для хорошего развития языка
ts01

@Shamim: начните с php.net и wiki.php.net.
StasM

4

Большинство хороших языков есть и стремятся быть последовательными.

Это просто реальность состояния PHP. Как упомянул StasM, было бы кошмаром попытаться поменять такие вещи после свершившегося факта. Это повлияет на слишком много существующего кода. Часто PHP просто отказывается от функций и создает новые более совершенные функции, которые более согласованы, но это может занять много времени.

Я думаю, что успешные программисты PHP либо помнят конкретный синтаксис, либо используют программное обеспечение, которое автоматически сообщает им синтаксис.


амортизирующая функция - это одно, легкое.
Менять

@ ts01 прибивает существенную проблему. Имея только позиционные параметры, невозможно узнать, что ваш существующий foo(a,b)теперь должен быть, foo(b,a)потому что кто-то изменил подпись foo.
Фрэнк Шиарар

@ TS01, @Frank: Вы должны были бы изменить название функции, тоже ... не особенно хорошая идею вещи , как «property_exists» там , где не нет другого приличного имени. Лично я хотел бы, чтобы массивы стали реальными объектами, чтобы вы могли сказать, $array->key_exists('whatever')но, ме-хе :-)
Дин Хардинг

Фактически, то, что может сделать любой PHP-разработчик, - это создать свои собственные новые функции, чтобы обернуть их. Также обратите внимание, что isset () имеет универсальный синтаксис для обоих упомянутых примеров, но они просто не рекомендуется как часть скомпилированной спецификации.
user1122069

3

Основным источником несоответствия является то, что многие (большинство?) Из php встроенных функций действительно являются обертками вокруг некоторой библиотеки C. Первоначально я думал: «Я обертываю C-функцию xxxx, поэтому я должен сохранить порядок параметров таким же». Когда дело дошло до написания функции «чистого php», это мышление было расширено до «xxxx берет файл и параметры», новая функция принимает имя файла и параметры, поэтому имеет смысл, чтобы yyyy принимал те же параметры в том же порядке.

Большой недостаток заключается в том, что базовые библиотеки C были очень непоследовательными с самого начала.


Они также сохранили имена функций C, которые они оборачивали в некоторых случаях (в частности, функции str), в то же время сильно отклоняясь от соглашений C по присвоению имен (таких, как они) для других имен функций.
Дэн Рэй

2

Причина (a?) Заключалась в том, чтобы оставаться совместимым с предыдущими версиями PHP. Вместо изменения имен функций, которые могут нарушить работу многих приложений, функции остаются. Тем не менее, интуитивно, да, согласованное именование функций должно учитываться для новых языков.

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

Совместимость> Согласованность (по крайней мере, для PHP)


1
Другие языки я могу писать без постоянной ссылки на документы. PHP Я всегда должен беспокоиться о ... эта функция пишется "str_" или просто "str"? Это «массив _» - что-то или мы не упоминаем массивы? Что делает "length ()", когда передается строка? О, черт, нет, это "strlen ()", я действительно хотел ... Это "иголка, стог сена" или "стог сена, игла"? Никакой другой язык не проходит через все это.
Дэн Рэй

Как и вы, меня постоянно беспокоил этот @DanRay. Сейчас я начал использовать PHP IDE NetBeans, который дает мне точную информацию, которая мне нужна, прямо в редакторе.
deed02392
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.