Сергей Протько

Сам объект находится в памяти, и все переменные хранят в себе ссылку на объект. Тут скорее наоборот в java проще, потому что нет возможности передачи самих объектов, только ссылки.

А в C++ я могу создать переменную, которая ссылается на объект, могу создать переменную, которая ссылается на область памяти, где хранится объект, могу создать ссылку на переменную, которая хранит ссылку на объект, который хранится в памяти. И память я должен выделять и чистить сам, поэтому в С++ возможно передать ссылку на объект в памяти, который уже не существует, и при использовании вы "выстрелите себе в ногу" с segmentation fault. Как-то так.

Ни как. В Java мы работаем только со ссылками на объекты.

This class behaves the same as DateTime except it never modifies itself but returns a new object instead.

RTFM.

В настоящее время придерживаюсь следующей схемы:

На стороне сервера вначале идёт проверка авторизован пользователь или нет. Если нет, то смотрится с корневого ли роута он пришёл. Если не с корневого то делается редирект на корневой. Для корневого роута неавторизованному пользователю показывается login-page с тупой формой авторизации.

А вот если пользователь уже авторизован, то такой запрос отправляется на React-router, где с контентом страницы на клиентскую сторону в том числе выплёвывается и бандл с клиентским кодом.

Если кратко, то вся изоморфная котовасия (+ соединения по сокету если у вас realtime) начинает работать только для авторизованных клиентов.

P.S. Извиняюсь если сумбурно вышло.

Не надо так делать. Найдите у вашего плеера нужное событие и подпишитесь на него

Первый вопрос который меня интересует это PSR-0 или PSR-4. На сколько я понял по состоянию на 21 октября 2014 года PSR-0 был помечен как устаревший.

PSR-4 не замена PSR-0, а дополнением к нему.
github.com/php-fig/fig-standards/blob/master/accep...

про PSR-3 я вообще как-то не нашел русскоязычной информации, словно такого стандарта нет

Видать, не перевели. Читайте в оригинале:
github.com/php-fig/fig-standards/blob/master/accep...

/path/to/project/ это путь к проекту и данный путь нигде не фигурирует, это та директория из которой запускается основной index.php

Да, это пусть к PHP файлам проекта. Но index.php обычно выносят в отдельный каталог (например, /public), а все классы проекта хранятся, например, в /src (или /lib или ещё как угодно). В конфигурации веб-сервера запрещают отправлять запросы к любым файлам, не лежащим в /public, благодаря этому /public/index.php является единственной точкой входа для внешних запросов.

./vendor это папка назначение которой я не понимаю

Это папка для сторонних библиотек, используемых в вашем проекте. Используется composer'ом. Внутрь лезть особо причин нет, composer сам решит как ему там всё разложить. Свои классы вы туда тоже не должны писать.

в итоге честно говоря я запутался в том как правильно надо строить свои каталоги, какие папки обязательные какие нет, когда использовать src, когда lib, когда tests, почему в некоторых структурах приходится дважды указывать имя поставщика и имя пкета и т.д.

src и lib - скажем так, синонимы. Кому как больше нравится. Главное, что внутри лежат сами PHP файлы проекта, следующие стандарту PSR-4. Лежат там только файлы, написанные авторами проекта. Поэтому нет смысла класть vendor внутрь src (или lib).
test - каталог для тестов проекта.
В папке vendor имя поставщика и имя проекта могут совпадать, вот они и дублируются.

Так как вы изобретаете свой велосипед, то и структуру каталогов делайте свою, или посмотрите на популярные CMS/фреймворки, но везде будет по-разному. Joomla, WordPress, Yii, Zend Framework, Symfony.

Я придерживаюсь такой структуры:

/config                     Глобальные настройки проекта.
/data                       Временные файлы. Например:
/data/cache	            Файлы кеша.
/data/logs	            Логи.
/data/tmp	            Прочие временные файлы.
/module                     Модули проекта. Например:
/module/Backend	        
/module/Backend/config      Настройки модуля.
/module/Backend/src	    Файлы PHP модуля. Например:
/module/Backend/src/Backend/Path/To/ExampleClass.php
/module/Backend/test	    Unit-тесты модуля.
/module/Backend/view	    Шаблоны модуля.
/module/Frontend/...
/public/index.php
/public/css
/public/font
/public/img
/public/js
/vendor

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

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

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

History API в этом деле краеугольный камень, потому что именно он позволяет управлять адресной строкой страницы без ее перезагрузки, используя обычные ссылки без #
Схема такая - вы кликаете на ссылку, ее отлавливает скрипт, забирает из ссылки url, через History API заменяет адрес в адресной строке браузера (страница не перезагружается), срабатывает History API событие об изменении адреса в адресной строке, вы это событие перехватываете и скармливаете новый адрес роутеру, например вашему изоморфному.

var http = require('http');
var phantom = require('phantom');
var app = http.createServer(function (req,res) {
    res.writeHead(200);
    res.write("Hello world");
    phantom.create(function (ph) {
      ph.createPage(function (page) {
			  page.open('http://google.com/', function() {
			    console.log('create screen');
          page.render('google.png');
        });
	    });
    });
  res.end();
}).listen(8080);
console.log("listening on 8080");

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

Если у вас есть такие ссылки, то они должны показывать то что там будет, вне зависимости от того как открыли этот адрес.

Только делается это ПОСЛЕ загрузки страницы средствами роутера JS, а не перед загрузкой страницы как "обычно"

Даны 2 слова, определить можно ли из 1 слова составить 2, при условии что каждую букву из строки 1 можно использовать только один раз?

Если это читается как "определить можно ли из первого слова составить второе", то алгоритм прост:

1. Собрать все буквы первого слова в массив.
   
2. Собрать все буквы второго слова в массив.
   
3. Найти разницу первого массива со вторым - если ничего не вернулось, значит второе слово можно составить из первого.
   

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

чем Вам momentjs.com не угодил???