Vladimir Onokhov

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

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

Тут - проще объяснить применительно к конкретным языкам разработки и технологиями. Например время доступа к элементу хеш таблицы Java (HashMap) оценивается как O(1). Тоесть время всегда постоянное и не зависит от прочих условия типа размера таблицы. А если у нас вместо хеш-таблицы - красно-черное дерево (TreeMap) - то тогда время доступа оценивается как O(log n). Тоесть логарифмически зависит от размера данных в дереве.

Считается что O(1) лучше чем O(log n). Но этот тезис действует на объеме данных близком к бесконечности. На малых объемах структуры - неразличимы или могут менять свои свойства в зависимости от разных начальных условий (были ли в кеше L1/L2/L3 до этого уже прочитанные данные).

Время работы алгоритма - константа. Т.е. не зависит от размера входных данных (или их нет вообще)

Сложность алгоритма + и еще

Знать все основы языка, ориентироваться в стандартной библиотеке и знать где искать ответы на возникающие вопросы
Это минимум

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

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

Подымая мысль о том, что фреймворк заботится о безопасности делая много вещей из коробки - добавлю, что в эпоху тех самих микросервисов ты либо будешь учить микро-фреймворк, который этого не делает, либо тебе скажут, что "на этом сервисе у нас только авторизация, а ты сюда зачем-то прикрутил троттлинг, ддос защиту, csrf защиту, защиту от иньекций и всё это вместе". Это все сжирает драгоценные миллисекунды и что важно - может быть сделано на других слоях тоже. В какой-то конторе крутой девопс способный сделать это на линуксах, в другой конторе были талантливые программисты, которые написали слой авторизации, который это уже делает за тебя и девопс это обернул так, что штука, которая разворачивает сервисы при каждом запросе это сама делает для тебя, а твое приложение делает это ещё раз.

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

Ну, по-хорошему, ещё рановато.
Всё-таки, фреймворки служат для ускорения разработки веб-приложений, а не одностраничных черновиков.
При чем это очень важный момент.
Не использовав в своей работе всё, что требуется при разработке веб-приложения (в том числе безопасность, следование рекомендациям протокола НТТР, валидация данных, и примрно ещё десяток нужных вещей) - то не сможешь реально понять, как много фреймворк делает за тебя.

Стоит сейчас, но неглубоко. Просто понять основные принципы и зачем вообще нужен ООП.
Что бы если что-то встретится - понимать о чем речь. И дальше учить php по какому-нибудь курсу и делать заказы, если они есть.
Из хороших преподавателей которые есть в сети - могу рекомендовать Лаврика или Борисова.

В простеньких приложениях ООП приложить некуда будет.
Начнется борьба с собой: почему тут надо наворачивать такие сложности, вот же тяп-ляп - и работает.
ООП - способ упорядочивания сложного, объемного кода.
Берясь за более сложные задачи на Пыхе, сейчас, имхо, пройти мимо ООП сможет только человек, который защищен законами США от электрического стула (это имеющий IQ ниже 70).

Я-бы смотрел на вопрос через потребности фреймворка. Что щас популярно под ПХП. Ларавел. Вот надо глянуть какой там уровень ООП. Как он его использует. Какой сет фичей. И вот только по ним и работать.

Изучать ООП - как таковое - это большая ловушка для любого разработчика. Там и теоретики не могут сойтись на мнении что оно есть и как оно есть. Короче можно 5 лет просидеть и только обрести новые вопросы и парадоксы.

Я бы прочёл документацию там это в 6 или 7 главе

Сейчас самое время начать))

Чат это хранилище переписки и способ их доставки.

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

Но в пхп есть работа с сокетами используя команды stream_*, чтобы подключить обоих участников (подписать) к третьему серверу и он принудительно присылал ожидающим сообщения обновления как только они придут на сервер.

Если это будет консоль двух клиентов и консоль сервера то столкнешься с проблемами на windows, где у cmd.exe нельзя писать в консоль и одновременно слушать соединение с сервером, только по-очереди, на линуксе - можно. В смысле и там и там по-очереди, просто винда не умеет до завершения того как ты печатаешь быстро переключаться между "послушать сокет" и "послушать ввод юзера" - слушает ввод юзера пока enter не нажмешь.

Если будешь делать морду на html, будешь использовать либо периодический опросник с "морды" клиента на javascript к серверу через асинхронные запросы (ajax), либо будешь применять пакет для javascript socket.io и протокол веб-сокетов, чтобы уменьшить задержку между получением с "времени опроса" до "как только пришло сразу показать".

Так же, как на любом другом языке. В минимальном виде надо два обработчика: Один будет выбирать из базы сообщения и отдавать их клиенту вместе с формой, а второй будет принимать из этой формы сообщение и записывать его в базу.

Каждый выбирает свой способ постичь дзен в выбранном языке. Но у большинства одно и то же направление. Мой подход не сильно отличается от остальных, но есть свои моменты.
1. Во первых лучше всего вспомнить что вы раньше не имея навыков программирования желали сделать и поставить это своей целью. Описать все это где-то на электронном или бумажном носителе, так как если вам на данный момент кажется что все предельно ясно и вас ночью разбудить и вы все это наизусть произнесете, будьте уверены что после кучи часов искания как вам реализовать тот или иной момент вашей задачи вы будете помнить лишь очертания задачи, а тонкости уже не будут такими ясными и результат будет меняться...
2. Вам явно не стоит пытаться реализовать что-то стандартное которое везде описывают, так как вы научитесь просто читать статьи и туториалы и копировать строки оттуда в свой код, вы извините, но человек существо ленивое и почти всегда выбирает путь наименьшего сопротивления.
3. Даже реализовав проект вы получаете навыки постановки себе задач и их реализации, но вы все еще остаетесь начинающим программистом. дело в том что за свои почти 15 лет в РНР я не раз встречал работу РНР кода отличающуюся от ожиданий(и даже документации, либо же недокументированное поведение определенных комбинаций кода), а это уже - опыт...
4. изучать фреймворки это клево и нужно, но пытаться сразу выделить себе какой-то фреймоврк и строить задачи на нем - не верно, вы научитесь лишь его функционалу, но понимание того как это делает за вас фреймворк - останется черным ящиком. а если вы посмотрите логи обновления версий фреймворка, то вы увидите сколько там происходит изменений и обновлений в логике, что уже означает - мало того что вы будете принимать на веру то что в черном ящике, так еще и от версии к версии это может совсем не так работать как вы приняли на веру в момент изучения...

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