Кто-нибудь еще использует PHP < 5.4?

mendel, поищите термин information hiding, вы путаете его с инкапсуляцией. Точнее, это один из частных случаев инкапсуляции. А то что я приводил ранее (пример с людьми) - явное нарушение самой инкапсуляции, и можно долго говорить о том, что это фича. На самом деле, это уродство ;)

danforth, еще раз. Это ВЫ решили что данный функционал языка ДОЛЖЕН решать изоляцию данных. Авторы языка решили что он должен решать задачу изоляции АПИ. И описали это в документации.

Спор о том где проходит граница сокрытия и инкапсуляции и какой из множества подходов к этим парадигмам более верный - явный холивар.

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

Кто больше виноват в том что вы не поняли суть задачи - документация или ваше видение я не знаю. Думаю документация. Определять что правильнее и важнее, я не готов.

---------- Добавлено 21.03.2017 в 18:24 ----------

Пожалуй скажу еще раз иначе.

Приведите РЕАЛЬНЫЙ кейс где дополнительное скрытие по принципу данных а не кода дало бы практическую пользу, а такое сокрытие неудобно.

Их нет.

Просто неожиданность, не более.

Мы обращаемся ИЗ ТОГО ЖЕ класса, так что все на виду, забыть мы не можем.

Строить логику на ошибках доступа? Это даже не прерывания. Так что бред.

А от ошибок программиста в виду неинформированности/независимого изменения оно нормально защищает и так, ведь изменения в одном файле.

Так что ничего кроме удивления тут нет.

mendel, да это бесполезный разговор. Вы говорите:

На самом деле есть, и это безопасность данных. А вот этот прямой доступ при закрытых свойствах/методах никакого удобства не несет на самом деле. Вы часто пользуетесь этой особенностью? Хорошо, такой вопрос: есть плагин, который по хуку принимает некий объект. Плагин не использует рефлексию, хотя хз как это поможет в данном вопросе. Инстанс плагина и инстанс объекта, который он принимает, не одного класса (т.е. не как в прошлом примере). Ну, скажем, somePlugin::doSomething(User $user). Вопрос, что потенциально может этот плагин по отношению к объекту, который он принял в аргумент?

а) Ничего не может, кроме того, что задекларированно как public

б) Может прочитать приватные свойства и использовать приватные методы

в) Может изменять приватные свойства

г) Может делать с объектом что угодно

Второй вопрос звучит так: какого бы поведения хотели вы?

На оба вопроса ответ:

Объясню почему.

Сначала ответ на первый вопрос - в общем случае можно пытаться спрятаться.

Но у нас есть как минимум сериализация/десериализация.

Есть "особенности" с итераторами/итерацией, преобразованиями в итератор, вар_дампами и прочими вещами. Как не прячься, а прочитаешь по-любому.

Имея все внутренние состояния и сам объект - подменить его не составит большого труда.

Есть только одна тонкость, особенность устройства eval, про которое я рассказывал. Объект у нас есть, делать с ним мы можем все что угодно, но запихнуть полностью другое значение в вызвавший нас скоуп мы не можем, ведь по факту нам передают по ссылке не объект, а ссылку на значение объекта.

Но у нас есть как минимум конструктор. Если это не синглтон, то он у нас публичный. И никто не запрещает его вызвать повторно (Черт! Проклятый пхп меня так подвел в свое время - PDO может сразу в объект данные лить, но конструктор при этом не вызывает, магические __сет не использует "и вообще!").

Опять таки - через вот такие кривости впихнуть данные можно будет всегда. Доступ к данным объекта то у нас есть.

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

Но, уверен что всегда можно будет это сделать.

Вы скажете что это всё кривой пхп? А вот нифига!

У всех такое есть. Особенно у "взрослых" языков вроде того же С++.

Точнее там еще проще.

Память то хардкорно доступна.

Ну и теперь по второму вопросу. Почему я хочу чтобы было так, как оно и есть?

Просто потому что иллюзия безопасности хуже чем ее отсутствие.

Получил доступ к коду, получил доступ ко всему что может пользователь выполняющий код. Всё.

Песочница совсем не так делается. Да и из песочниц регулярно выбираются :)

mendel, я понял вашу позицию, и, отчасти согласен с вами. Для прямого доступа к значениям в памяти в языках типа C++ есть причины, точно такие же, как отсутствие прямого доступа к памяти в PHP. Это как переключение режима огня на винтовке, и "Замок от детей" на стиральной машинке.

Универсальный способ залить: http://pastebin.com/ky6dDc7e

Прикольно.

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

По идее мы и ограничение "не по ссылке, а копия ссылки" так обходим.

Собственно ЧТД.

Немного на вентилятор.

Мы тут такие все умные, красивые.

Я вон о строгих таипхинтах задумываюсь.

А меж тем библиотеки которые мы используем....

Ну вот глянул свои внешние зависимости из проекта которому таки передвинул минимальную планку с 5.4 на 5.6:

PhpMailer

HTMLPurifier

Adminer (только встраиваю, но не суть)

less.php

Неймспейсы? Какие неймспейсы? Сейчас что 2017 год чтоли? Совместимость в пхп7 есть, но неймспейсы использовать?

Это одни из самых популярных библиотек.

Большинство из коробки композером тянется и все такое. Обновляемые свежие репозитории. PSR в основном соблюдаются, псевдонеймспейсы, все такое)...

Так, бурчу просто)