Два раза запрягать?
Сегодня перевести ЧАСТЬ сайта, чтобы завтра все равно перейти всем сайтом?
Прикольно.
Не особо любитель замыканий, не думал что вот прям так, без мыла.
По идее мы и ограничение "не по ссылке, а копия ссылки" так обходим.
Собственно ЧТД.
На оба вопроса ответ:
Объясню почему.
Сначала ответ на первый вопрос - в общем случае можно пытаться спрятаться.
Но у нас есть как минимум сериализация/десериализация.
Есть "особенности" с итераторами/итерацией, преобразованиями в итератор, вар_дампами и прочими вещами. Как не прячься, а прочитаешь по-любому.
Имея все внутренние состояния и сам объект - подменить его не составит большого труда.
Есть только одна тонкость, особенность устройства eval, про которое я рассказывал. Объект у нас есть, делать с ним мы можем все что угодно, но запихнуть полностью другое значение в вызвавший нас скоуп мы не можем, ведь по факту нам передают по ссылке не объект, а ссылку на значение объекта.
Но у нас есть как минимум конструктор. Если это не синглтон, то он у нас публичный. И никто не запрещает его вызвать повторно (Черт! Проклятый пхп меня так подвел в свое время - PDO может сразу в объект данные лить, но конструктор при этом не вызывает, магические __сет не использует "и вообще!").
Опять таки - через вот такие кривости впихнуть данные можно будет всегда. Доступ к данным объекта то у нас есть.
Честно, вот так вот в рамках спора универсальный способ залить не предложу.
Но, уверен что всегда можно будет это сделать.
Вы скажете что это всё кривой пхп? А вот нифига!
У всех такое есть. Особенно у "взрослых" языков вроде того же С++.
Точнее там еще проще.
Память то хардкорно доступна.
Ну и теперь по второму вопросу. Почему я хочу чтобы было так, как оно и есть?
Просто потому что иллюзия безопасности хуже чем ее отсутствие.
Получил доступ к коду, получил доступ ко всему что может пользователь выполняющий код. Всё.
Песочница совсем не так делается. Да и из песочниц регулярно выбираются :)
danforth, еще раз. Это ВЫ решили что данный функционал языка ДОЛЖЕН решать изоляцию данных. Авторы языка решили что он должен решать задачу изоляции АПИ. И описали это в документации.
Спор о том где проходит граница сокрытия и инкапсуляции и какой из множества подходов к этим парадигмам более верный - явный холивар.
Решение реализованное в пхп выполняет ту задачу которую на него возложили единственно правильным и очевидным образом, если понимать суть этой задачи.
Кто больше виноват в том что вы не поняли суть задачи - документация или ваше видение я не знаю. Думаю документация. Определять что правильнее и важнее, я не готов.---------- Добавлено 21.03.2017 в 18:24 ----------Пожалуй скажу еще раз иначе.
Приведите РЕАЛЬНЫЙ кейс где дополнительное скрытие по принципу данных а не кода дало бы практическую пользу, а такое сокрытие неудобно.
Их нет.
Просто неожиданность, не более.
Мы обращаемся ИЗ ТОГО ЖЕ класса, так что все на виду, забыть мы не можем.
Строить логику на ошибках доступа? Это даже не прерывания. Так что бред.
А от ошибок программиста в виду неинформированности/независимого изменения оно нормально защищает и так, ведь изменения в одном файле.
Так что ничего кроме удивления тут нет.
Вы путаете теплое с мягким.
То что в пхп нет единообразия в функциях это неоспоримо, и не проблема документации. По документации претензия частично отдельно от дискуссии, частично в контексте вашего непонимания сути привата.
Всё хорошо в меру и к месту.
Это отличное решение, но не стоит им злоупотреблять.
Если 100500 лампочек то нужен "делюминатор", например пульт управления. А для единичного случая такая фишка с двумя выключателями очень даже удобна. Да и дешева до безобразия. Большинство обычных выключателей легко затачиваются под эту задачу. А решения принимаются на базе того что ты видишь - свет есть или нет. Нужно изменить, или не нужно. Удобнее чем бегать за выключателем.
С другой стороны StateLess подходы да, во многом проще.
Мне например надоело отслеживать "кто платил за кофе вчера" на утренней планерке которую мы проводим с партнером в кофейне рядом с офисом (вдали от остальных сотрудников) - я предложил платить не по очереди а по четному и нечетному числу). Учитывая что в основном пятидневка, и 31 может придтись как на выходные так и на будние, то погрешность от "справедливости" незначительна.
Зато голова свободна от лишней информации и мне забавно использовать компьютерные технологии в обычной жизни.---------- Добавлено 21.03.2017 в 16:54 ----------
Это очень нравится вам или мне. Но явно не понравится пану SeVlad, а особенно его менее опытным коллегам по подавлению слов.
Не разделяю позицию edogs в этом вопросе, поскольку ужесточение и нагромождение синтаксиса не от хорошей жизни, а от необходимости писать и поддерживать более СЛОЖНЫЕ вещи, но тем не менее факт, что вчерашнему дизайнеру разобраться даже с неймспейсами - тяжело.
Бррр....
Сплошные антипаттерны.---------- Добавлено 21.03.2017 в 12:52 ----------
О пхп такого не скажешь к сожалению.
Но это не тот случай.
Здесь речь не про удобство, а про то что оно выполняет ровно те функции которые и должно. Возможно проблема в документации.
Точно проблема в том, что нет какой-то сертификации чтоли?
Люди думают что сухой справки из документации им хватит чтобы понять, при этом сами не имеют внятного опыта и мышления программиста, и не очень понимают что это и зачем.
Это не лично к вам. Это ко всем.
Из моих знакомых которые понимают "шо почем" - большинство учились как я через множество шишек, и доростание до того что нам хотят сказать своим умом.
Небольшая часть это те кто пришли из тяжелых и нудных языков (или и не уходили), и имеют академическое ИТ-образование. (Одного образования при этом совсем недостаточно, как правило академическое образование делает людей заучками, которые понимают медленнее, ведь они всё _знают_).---------- Добавлено 21.03.2017 в 13:02 ----------Меж тем динозаврофилы уже почти догнали динозаврофобов.
Сам? Или ты ему помогаешь?)
Вообще по протоколу спрашивать положено, если там пост-данные есть.
Да и вообще на серче обычно аяксом сообщения отправляют.
Но не суть. Ок. Мы договорились что помимо проблемы с конекшинами БД у серча бывают еще проблемы при плохом интернете. Дальше спор действительно не в тему будет ибо лечить мы эти баги не будем.
Да, да, и еще раз да.
кто понял жизнь, тот таких вопросов не задает))))
Да, это капец-капец.
Но нам приходится пользоваться пхп потому что он самый популярный.
Это разные мысли?
Нет!!!
Это две стороны одной медали!!
Пхп самый популярный потому что в нем все так криво.
Да!
Почему у него все так криво?
Потому что на скорую руку запихнули в него все доступные под руками библиотеки. Из Си, из чего угодно. Именовали всё - как было там где тащили.
Главное побольше "ножей" и побыстрее.
Почему пхп самый популярный? Потому что к тому времени как другие вылизали свои детища - место под солнцем было уже занято). Да!
Нет, я конечно слегка упрощаю. Есть много других факторов,но в целом общая тенденция у всего этого именно такая.
И да, пхп понемногу старается от всего этого наследия вычищаться.
Вон explode/implode уже сто лет как синхронизировали, в ООП версиях тех же функций - большее единообразие, и все такое. В пхп9/пхп10 будет уже более менее порядок + куча депрекейтета который еще не выкинут вплоть до пхп50.
А вы точно психолог? (с)
Приватные/защищенные методы/переменные это не о том о чем вы думаете.
Здесь главное обеспечить SOLIDность кода. Не защищенность объекта, а отсутствие необходимости разработчика знать внутреннюю реализацию используемого им класса. Защищать объект не нужно, да и невозможно.
Приватные члены используются только в этом классе. Если мы пишем что-то в этом классе, то мы знаем все что в нем есть, и эти члены тоже.
И значит может использовать их как хочет.
При этом тот кто вызывает класс извне - его не знает, и не видит.
И тот кто от него наследуется, он не знает и не видит.
Т.е. это внутреннее апи чисто этого класса.
Если мы берем защищенные члены, то это то АПИ которое предназначено как для внутреннего использования, так и для тех кто должен (или может) нас наследовать. При этом тот кто использует готовый объект нашего класса - знать этот апи не должен, так что это апи от него скрыто.
Паблик доступен всем извне, ну и внутри тоже, ведь это то, что мы заложили в ПУБЛИЧНЫЙ апи нашего объекта.
В вашем примере апи приватное, используется приватно, в рамках класса.
Всё логично. Задача инкапсуляции выполнена хорошо.
Другое дело что это не особо нужно. Я бы никогда не узнал об этом, потому что вот так вот дергать приватные свойства не очень красиво. В идеале такие вещи лучше вынести в паблик, но в принципе если будет какая-то реальная задача где "мы с Тамарой ходим парой", и некие объекты так тесно связаны, что есть смысл лезть во внутренности другого объекта своего класса, но нельзя давать это в публичное АПИ, то почему бы и нет? Чисто исходя из логики ООП реализация с инкапсуляцией по коду, а не по экземпляру мне кажется более логичной, хотя более кривая логика (та что вы ожидаете) тоже не проблема, она просто другая.
Ну их блин много, и документация у пхп кривая если честно.
Помогает не столько то что ты документацию читал, сколько понимание жЫзни.
Когда тебе нужна какая-то функция, и ты понимаешь что в принципе она должна быть в апи, а не гуглится на стековерфлоу. А вот эту функцию лучше искать там, кто-то уже написал, а вот это можно даже не искать, до тебя никто не писал...
Ну честно говоря я как в ИДЕ включил проверку PSR, так периодически у себя нахожу опечатки. Раньше у меня в проекте был другой стандарт, пробежался, переделал, но где-то затерялось. Узнал чисто когда впервые увидел что код который давно проверенно работает содержит такую опечатку. Удивился, как-так то, полез в доку, увидел что независимые, поржал, ну и ладно.
А вот мой пример с "передачей по ссылке" всех объектов - чисто следствие внутренней реализации. И тут как раз может сложиться ситуация когда хочется не просто поменять свойства объекта переданного в функцию, а тупо его заменить чем-то, и привычка что раз мы можем его менять, то значит он по ссылке, может сыграть с нами злую шутку. Но... у всех бывают странности.
Меня больше удивляло что в пятом пхп пхп4-стайл конструкторы не были депрекейтет, и убрали его только в седьмом, да еще и с таким количеством воя.
(Сам на это нарвался буквально полгода назад, в пхп5.6 на рефакторинге переименовал один класс, и тут вдруг перестал работать большой кусок.
Рефакторинг был довольно механический, так что тестировал сразу большой кусок, ну что там проверять то? Поэтому довольно много времени взяло понять что один метод вдруг превратился в конструктор.)---------- Добавлено 21.03.2017 в 10:34 ----------
Конечно были. Я же сказал - в основном.
Там собственно два кейса - или говносайт, или крупный сайт.
Либо ты используешь потенциально проблемную бортовую функцию (говносайты), либо ты умеешь ее правильно готовить (приличные сайты со своим сервером и админом). Но среди нормальных сайтов второй кейс редкий, а первый отпадает.
Т.е. я к тому что "миллионы говносайтов и десятки нормальных".
Ну медленный. Ну нестабильный. И что?
У меня на истио.нет было настроено что дубли не проходили.
На продомейнере тоже проверил только-что:
Ну вот не помню как я это делал, или плагин, или в ядре. Вообще ПД это последний форум на булке где я админ, и уже сто лет "под капот" не лазил. Как оно начнет отваливаться - скорее всего перенесем на какой-то блогодвиг или свой)
Через день сам пложу дубли именно от ошибки базы данных, хотя если обернуть в транзакцию и закрывать уже в конце страницы, то фиг оно при ошибке сохранится.
А медленный интернет.... ну бывает. Тут оба сценария нормально отработает - защита от дубля напрямую защитит от дубля. А оборачивание всего в транзакцию может защитить превентивно - отправили в браузер, закрыли транзакцию. Обычно этого хватит. Страница будет открываться долго, но откроется.
Другое дело, что тут нужно больше думать по плану запросов, чтобы не потерять производительность в ноль.
Но! в то время когда писалась булка - инодб была заметно медленнее (сейчас наоборот), и логично что транзакции не рассматривались. По крайней мере в массе. Аналогично - вордпресс ужасен по своему АПИ, но... когда он появился, он был идеален.
ПС: по идее оно все по теме, ибо древний/новый пхп и древние/новые паттерны/библиотеки/драйвера это близкая тема.
В свое время Дуров озвучивал такую позицию по файлам, чтобы не париться с дефрагментацией и т.п. С сообщениями много кто так делает. Вообще удалять данные безвозвратно гемморно, разве что ради высокой цели - приваси или экономия места. Экономии места тут не нужно, очень мало даст, а приваси? Да кому оно надо? У них проблем с приваси было постоянно очень много, в архитектуру никогда не закладывали. Уже после ухода из ВК Дуров стал чуток об этом думать... Плюс косвенно - после удаления есть кнопка отменить.
Самое простое - просто убрать потом эту кнопку после обновления страницы, но функционал так и оставить. Это было бы в духе команды Дурова.
Ну а когда Дуров ушел, так в стране такая цензура развелась, что смысла параноить вообще не стало.
Так что я не знаю, но почти уверен что там все ходы записаны "навечно".
Другое дело что логи могут очищать из экономии места, логов много, толку с них мало...
ПС: не читал по ссылке, лень.
У меня аргумент за PHP только один. Это LAMP и "тест зубной щетки".
Если я хочу чтобы мой фреймворк прошел "тест зубной щетки" (с) Гугл, то он должен в первую очередь работать под LAMP. Потом уже по одной меняем первые три буквы, чтобы и там тоже работало. А что до четвертой... вообще хочу. Но думаю что последняя буква не будет изменена никогда.
Видели под Java придумали GC который нифига не убирает?) Это не единственный случай когда Java развивается в сторону того, чтобы хорошо работать умирая. А PHP уже много лет двигается в сторону того чтобы мог не умирать. И то и другое весьма успешно получается.
Да не обязательно в голове держать.
Просто не нужно использовать экстремальных вещей, писать так как ты бы писал на другом языке, где тебе позволено не все, и ошибок тебе не прощают. Ну и тестировать, да.
