Как сохранить выбранное значение?

Очередное заблуждение основанное на суевериях 20-ти летней давности и "показательном" ООП примере hello world. Между PHP5 и PHP8 огромная пропасть.ООП парадигма как раз исключает дублирование кода, в то время как процедурный подход имеет склонность к копипасте и со временем превращается в новогоднюю гирлянду, которую с каждым годом всё труднее и труднее распутать.

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

Споры про ООП -- это же самое веселое, из того, что вообще было на этом форуме
Приятно видеть, что дело живет.
И, кажется мне, мы так и не поняли, что нам хотел сказать twin

brevis, спорят в основном те, для кого ООП не более чем процедурный код завёрнутый в классы. Тут надо смириться с тем, что пространственное мышление оно не для всех и просто не вступать в дискуссию. Просто с уважением отношусь к FatCat, поэтому не оставил комментарии без внимания.

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

FatCat, отличный пример. Только есть некоторая подмена понятий с твоей стороны.
Это как раз для ООП есть объект "крепление" и для объекта "картина" совершенно не важно на чём она будет висеть. Под "капотом" класса "крепление" может быть гвоздь, дюбель, шуруп и ещё хрен пойми что. В то время как в процедурном варианте будет только гвоздь или дюбель.
Ты скажешь: нет гвоздей есть шурупы.
А тебе в ответ: извини нужны гвозди, иди лесом со своими шурупами.
А ты такой: хорошо, я нашёл гвозди.
А тебе в ответ: ой, извини, братан, но не та длинна гвоздей, давай поднапрягись мы в тебя верим, у тебя обязятельно получится.

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

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

Да, бывает проблема незнания имеющихся средств. Памятная история двадцатилетней давности, когда мне нужна была функция поиска-замены по всему тексту. В php всё просто, str_replace, а в джаваскрипте такой я не нашел. Ну, не нашел и не нашел, написал свою:

txt = txt.split("A").join("B");

Если поиски-замены нужны не один раз, а в разных ситуациях, да, логично будет записать это функцией и обращаться к функции. Если один раз — нет смысла городить огород, заменил и заменил.