Или в случае, когда код вообще не выходит из этого цикла (только валится с исключением, если что-то пошло совсем не так).
Или условий выхода несколько, и каждый из них меняет состояние внешних переменных.
Или условие настолько сложное, что требует отдельного блока кода.
Или то, другое и третье вместе.
Эти попапы предупреждают об использовании cookies для идентификации пользователя.
Ну, отключи cookies в браузере, попробуй пожить в таком "отказе".
Собственно, приватный режим делает это за пользователя... правда, он не отключает, куки просто не сохраняются.
Андрей, ну, так в том и дело, что непохоже, чтобы у ТС была хоть какая-то архитектура. А советовать новичку, который не в курсе даже простейших решений, варианты, требующие архитектурного обоснования и понимания ограничений, согласитесь, нелогично.
Собственно, именно потому, что json-поля часто кажутся наивным велосипедостроителям серебряной пулей, решающей их корявые проблемы, использование этой технологии еще долго будет скорее признаком говнокода.
Андрей, просто Jason оправдан, когда ты готов вынести логику его разбора вне базы и уверен, что в запросах к базе она не понадобится.
А у ТС, похоже, с логикой работы с этими данными ещё чистое поле и никакого понимания, откуда они возьмутся и как будут обрабатываться.
Кстати, найденная вами инструкция - это перепечатка тем, кто не знает, что делает, инструкции, написанной неизвестно кем для системы восьмилетней давности. Не лучшее, что можно нагуглить по этой теме, мягко говоря.
Прав у рута нет, потому что даже руту незачем удалять что-то из папки /run.
Сервер не хочет устанавливаться, потому что не может остановить уже запущенный сервер.
Убейте его сами или просто перезагрузитесь, если вы реально поудаляли все его файлы из системы.
Если бы в окончательном варианте сервиса было так, как у ТС в ТЗ - возможно, json и был бы оправдан.
Но у него изложена ни к черту не годная логика, которая все равно работать не будет.
Еще и с json разбираться, переделывая?
Не знаю, как по PSR, но зачем писать "<?php echo" вместо "<?=" ?
Это настолько распространенный прием, что его даже при переходах с версии на версию боятся сломать.
ThunderCat, да я в курсе. Просто ФШ я начинал пользоваться еще с 4 версии (не CS4), а сейчас работа с ним не связана.
Но когда встают конкретные задачи, возникает вопрос, кому их выполнять - мне или нашим дизайнерам. Поневоле сравниваешь, сколько сил они бы потратили на ту же задачу...
Антон, поскольку речь у ТС конкретно про джаваскрипт, предлагаю его не сбивать с толку никакими наследованиями. В JS в подобных случаях все равно скорее используется не ООП, а объект данных с оговоренными полями.
Никита Егоров, нет, важно не исполнение, а именно уровень работы. Возня с файликами, байтиками, строками и прочими сокетами и базами данных - низкий уровень. Логика, в которой в определенном порядке дергаются эти методы нужных объектов - следующий.
У вас, скажем, для реализации в ООП-стиле должно быть не 4 метода, а три класса: парсер входящих данных, обработчик запроса и рендер ответа. Код, описывающий их создание и вызов нужных методов, будет высокоуровневым. И в нем будет видно только, что вы делаете в целом. Без всяких ненужных на этом уровне деталей. Кому надо разобраться в деталях парсера - лезет его код и локализует свое внимание конкретно на парсинге, забыв обо всем остальном. Понадобилось парсить другие данные - вы переписываете только парсинг, прочая логика не затрагивается.
Никита Егоров, для ООП неважно, линейная у вас обработка или нет. Важно, есть ли у вас возможность разделить процесс на разные уровни абстракции. Если какие-то детали важны только внутри обработки - их стоит убрать внутрь методов класса. Чтобы в том коде, который потом кто-то будет за вами читать, было сразу понятно, что В ЦЕЛОМ происходит. И только для того, чтобы разобраться, КАК ИМЕННО оно проделывается, нужно было лезть в код низкоуровневых методов. ООП - не для того, чтобы код был оптимальнее или легче писался. А в первую очередь - для того, чтобы он легче читался и модифицировался без переписывания одного и того же.
Антон, Антон, "терминологические споры, товарищи!"
Для примитивного примера того, как все сложности убираются с глаз долой, оно подходит.
То, что в js ООП такое, что там подобные кейсы решают простым приляпыванием функции к объекту - ну совершенно неважно для объяснения этого принципа.
Или условий выхода несколько, и каждый из них меняет состояние внешних переменных.
Или условие настолько сложное, что требует отдельного блока кода.
Или то, другое и третье вместе.