mendel, я понял вашу позицию, и, отчасти согласен с вами. Для прямого доступа к значениям в памяти в языках типа C++ есть причины, точно такие же, как отсутствие прямого доступа к памяти в PHP. Это как переключение режима огня на винтовке, и "Замок от детей" на стиральной машинке.
Универсальный способ залить: http://pastebin.com/ky6dDc7e
mendel, да это бесполезный разговор. Вы говорите:
На самом деле есть, и это безопасность данных. А вот этот прямой доступ при закрытых свойствах/методах никакого удобства не несет на самом деле. Вы часто пользуетесь этой особенностью? Хорошо, такой вопрос: есть плагин, который по хуку принимает некий объект. Плагин не использует рефлексию, хотя хз как это поможет в данном вопросе. Инстанс плагина и инстанс объекта, который он принимает, не одного класса (т.е. не как в прошлом примере). Ну, скажем, somePlugin::doSomething(User $user). Вопрос, что потенциально может этот плагин по отношению к объекту, который он принял в аргумент?
а) Ничего не может, кроме того, что задекларированно как public
б) Может прочитать приватные свойства и использовать приватные методы
в) Может изменять приватные свойства
г) Может делать с объектом что угодно
Второй вопрос звучит так: какого бы поведения хотели вы?
mendel, поищите термин information hiding, вы путаете его с инкапсуляцией. Точнее, это один из частных случаев инкапсуляции. А то что я приводил ранее (пример с людьми) - явное нарушение самой инкапсуляции, и можно долго говорить о том, что это фича. На самом деле, это уродство ;)
А куда он идет? Это ZF туда идет, точнее я бы даже сказал что взглянув ретроспективно, Zend наоборот идет оттуда в сторону простоты конструкций, разве что неймспейсы визуально ухудшают вид. Возьмите Laravel, и вам покажется что PHP идет в сторону Ruby. Я могу сказать одно: то что в PHP7 появился строгий type hinting, и возвращаемые значения, типы void и многое другое, это мне все очень сильно нравится.
Вы не поняли, видимо. На Lisp не пофиг, т.к. он не входит в стек веб-разработки. Мне не пофиг на те языки, которые у меня в подписи, + пару сторонних, которые скорее как хобби, нежели источник заработка.
Да нет уж, как раз таки касается. Не знаю как вы, а я частенько подглядываю в аргументы в IDE, и без неё уж точно бы не вспомнил где там haystack, а где needle, при этом всем я пишу 60% всего времени именно на PHP.
PHP прост как палка. Претензий по запутанности нет, если уж на то пошло, это один большой шаблонизатор. Есть претензии по интуитивности и нелогичности.
Вы привели пример кода на фреймворке, при этом говорите, что это похоронит PHP. Фреймворки нужно сравнивать между собой. Мы говорим о языке.
mendel, дело не в документации. Хорошо, приведу пример наглядный. Представьте себе дом, где 10 комнат, 3 этажа, красивая лестница. В каждой комнате есть выключатель света + софиты + всякие мелкие светяшки. Скажем, 10 * 3 = 30 выключателей по всему дому. Так вот, какая-то часть выключателей в режиме "Вкл - вниз", другая "Вкл - вверх". При этом есть выключатели на две и даже на три кнопки, и там тоже такая "фича", зато напротив каждого выключателя памятка. Вся такая цветастая, красивая. Ну как, плохая документация или плохие проектировщики/строители? Идем дальше: дверные ручки. В целом, 70% дома оборудовано дверными ручками буквой Г которые, однако оставшиеся 30% дверей имеют вот такой механизм, и что самое прикольное, открывают дверь они все по разному (одни нужно крутить по часовой, другие - против). Опять виновата документация? Как не крути, но ни один человек не запомнит все эти "фичи" этого дома, и если он будет там жить даже пять лет, он будет каждый раз ошибаться. Я, к слову, жил в квартире в которой был такой волшебный выключатель у лестницы, который от своего состояния срабатывал наоборот. Т.е., включил внизу свет, вверху выключил. Внизу теперь обратно нужно щелкнуть, чтобы включить, короче говоря, каждый раз по разному. Всего на лестнице было 3 вида подсветки: ступеньки, стена и потолок. Самый настоящий ад я вам скажу.
mendel, можно долго спорить на тему, удобно это или нет, но непрозрачное поведение - это непрозрачное поведение, как бы тупо это не звучало. Если палка похожа на пистолет, то есть вероятность, что она может стрелять? Нет. Вот так и в программировании должно быть. Чем меньше в языке есть вот таких загадок, где задав вам вопрос, вы не можете однозначно сказать: "Тю, так тут же все просто, свойство закрыто, а значит нихера у вас не получится", тем более интуитивно понятный и прозрачный язык. О PHP такого не скажешь.
Те, кто знает про существование альтернатив? Ладно вам заливать! Вот примеры:
На закуску:
class Human{ // очень приватное свойство, да? private $name; public function __construct($name) { $this->name = $name; } public function touch($human) { $human->name = "Ahtung"; return "Touched $human->name"; } public function getName() { return $this->name; }}
$name у нас приватное свойство, обратили внимание? Cоздаем два человека
$john = new Human("John");$sully = new Human("Sully");
Попытаемся прочесть имя Джона напрямую
echo $john->name; // Fatal error: Uncaught Error: Cannot access private property Human::$name
Супер, все у нас приватно, Джон приватный чувак. Идем дальше.
echo $john->touch($sully); // Touched Ahtung!
Джон потрогал Салли, но.. проблема. Салли = Ахтунг. Можно было бы подумать, что только в глазах Джона, но...
echo $sully->getName(); // Ahtung
А теперь вопрос: куда делась приватность? Это тоже фича? Мы не только прочитали свойство, мы смогли его изменить!
Полный листинг.
Аналогичный пример на Go (не хочу за него топить, просто первое что попалось под руку).
В Go свойства и методы бывают экспортируемые и неэкспортируемые: первые доступны во всем приложении, вторые только на уровне пакета. Для этого я сделал отдельный пакет с названием human. Свойство у struct закрытое (листинг файла). Вот основной файл с созданием Human'ов и попытками изменить приватное. В конце попытку изменить неэкспортируемое свойство нужно закомментировать, т.к. не скомпилируется. В результате имеем это:
Touched Ahtung // потому что все Human в одном пакете, и мы имеем доступ к name, мы можем его прочитать и заменить, но// так как в функции я передаю копию, то и изменения происходят над копиейSully // сам объект остается неизменным// попытки прочесть имя объекта sully напрямую приведет к тому, что программа не скомпилируется (чтение не из пакета, где объявлено свойство, а значит закрыто)
Добавлю, что в Go также есть подводные камни (фичи как вы их называете), например слайсы в фукнции передаются по ссылке, а все остальное - нет.
mendel, можно называть это как угодно, я называю это плохой архитектурой языка.
Язык популярный, да. Потому что когда появился, аналогов ему практически не было. Занял свою нишу, укоренился. А, как известно, лидера очень сложно потеснить. Но выбирая сейчас на чем писать проект, вряд ли выбрал бы PHP, если бы основным требованием не было "БЫСТРЕЙ!!11"
Можно найти неплохую статью по запросу "PHP: fractal of bad design", там очень огромный "послужной" список, а держать в голове все эти "фичи" нету никакого желания, но приходится.
saanvi, вы немного путаете.
Все что вы привели, это попытки приведения к типу. Убрали попытку приведения string => hex. А это, на секундочку, оптимизация работы со строками, т.к. нам не нужно до конца проверять строку "0х123", в PHP7 он вернет 0 уже на первом символе, в PHP5.x прочитает всю строку да ещё и совершит попытку сконвертировать строку в число.
За это и не любят ПЭХАПЭ, за то что каша и не прозрачное поведение и динамическая подлая типизация. Создатели пытаются хоть как-то навести порядок.
var_dump("php - gavno?" == 0); // true// python - false// js - false// php - true? WTF?!
https://jsfiddle.net/na6fs3gg/2/
