global раз и навсегда

Как раз меня это и не устраивает! Я делал замеры использование памяти и продуктивности оператора. global является указанием, что нужно использовать переменную за граню подпрограммы. global ничего не создает, в т.ч. ссылок! По всем тестам это работает лучше за заурядный сингтон. global = 1. указатель. Синглтон = 1. метод. 2. Метод set-get. 3. return. И в придачу ужасный синтаксис. Это часто бывает полезно, но не для глобальных массивов. Я уже говорил, что $_GET и прочее не зря сделано именно глобальным массивом, а не одиночкой. Вы согласны?

А не устраивает меня потому что нужно вести учет global (не дай Бог, где-то не напишешь) + опять таки шило на мыло по быстроте коддинга.

Закроем вопрос. Нельзя, так нельзя. Пока буду мучатся с Registry::.

Все, здесь я умываю руки. Это легко кстати проверить. Или как по вашему переменная становиться глобальной, откуда берутся данные? Это самая что ни на есть ссылка. У синглтона совсем другое назначение, я не понимаю к чему вы смешиваете в кучу паттерн со служебными переменными. Хотите глобальный массив, пожалуйста - $GLOBALS.

Быстрота кодинга это не только короткие переменные и синтаксис.

Хорошо. Ошибся. Это ссылка. Но все-равно это более оптимизированный вариант чем ООП.

Вот и я не понимаю. Я говорю вам о служебных переменных, а вы мне ООП предлагаете.

Не только писал бы, но даже пишу, и даже не только я. Можете посмотреть фреймоврки - у всех их есть такие фишки - служат для защиты от инекций разного рода - что не просто "не бред" но даже необходимость. Как думаете - столько людей могут ошибаться?

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

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

А если вам нужна простота - тогда вообще откажитесь от классов и функций, тогда все переменные будут глобальными ☝

Да? А я вот очищаю $_GET и записываю только те ключи, которые прошли валидацию. Представьте, делаю это без ООП!

Мне они нужны в первую очередь через наследование и эмуляцию неймспейсов, а уже потом объекты. Признаюсь, именно объект. контекст развит слабо. Но нужно различать объект от свойства, а не все писать в стиле ООП. Конфигурация это объект! И мне незачем обрабатывать то что я сам написал. А если и нужно будет, я сделаю это во время использования элемента массива.

Вы пишите ООП ради ООП. Усложняете программу и запутываете себя, пишите медленный код, которому не поможет никакой кэш. Задумайтесь-ка вы. ;)

ну, если глянуть CI первых версий - там тоже так, на функциях.

суть ООП в том, что при правильной логике - можно расширить функционал, не изменяя базовый код. Но это уже с другой оперы.

ООП ради ООП не пишется, ООП пишется ради расширения кода.

Да есть потеря немного в памяти под ООП - это его минус, на на фоне плюсов - теряется.

Я так понял, вы еще не пришли к понимаю, зачем нужен ООП и где реально можно потерять скорость работы скрипта?

GET нужно либо удалять либо хранить в оригинальном виде. Не понимаю, что вы там расширять собираетесь? Может вы еще пишите что-то типа Singleton::get('GET')['var']->toUpperCase(). Нее, ну извините, это бред, а не функционал.

ООП versus процедуры, это вечный спор. И давайте его не будем развивать. Машины любят больше процедурный код. Поэтому, если говорить именно об оптимизации программы, процедуры впереди. Если говорить о легкости масштабируемости кода, тогда ООП выигрывает. Но нужно тогда подстраивать ООП под себя. А если мне неудобен синглтон, зачем мне он? Что я выиграю используя ООП? - Только проиграю в производительности.

Мне дает существенный плюс использование DOMDocument в качестве шаблонизатора. Это действительно ООП. А вы небойсь используете регулярные выражения в шаблонизаторе. Вот видите какие мы разные. Я действительно контролирую качество, валидность кода, имею легкой доступ к классам и идентификаторам, а вы там GET в синглтоны пихаете. :D

Во-первых не только гет, но и пост и куки!

Во-вторых - когда мне оттуда нужно взять данные - перед тем, как их скажем записать/использовать в БД (не только гет, но и пост, куки) их нужно проверить. И намного проще написать 1 функцию под это на старте, чем каждый раз, составляя запрос в БД, обрабатывать.

А потом , скажем на каком то этапе ,мне понадобилась более серьёзная обработка - так я просто делаю расширение базового метода, а не переписываю его. ну и тд :)

bay_ebook, в GET, POST, COOKIE попадают только безопасные данные. И я работаю с ними как с безопасными, а не каждый раз вызываю их обработку. Шарите? :) Если мне надо например запретить html, я не лезу в методы, а в JSON карте допустимых значений переписываю TYPE на text с html и усе. Все входящие данные с определенным индексом записываются с вырезанными тегами (либо можно закодировать, как уже нужно будет :) ).

уберите шаблонизатор и получите такой плюс к памяти и быстроте, что все извращения с классами окупятся. Ведь по факту - пхп - это шаблонизатор для с++ для создания сайтов, а вы на один шаблонизатор другой. 🍿🍿🍿

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