Да, эти 2 пункта у нас есть. Только API для социального графа мы не делаем, поэтому назвать это аналогом SGAPI нельзя. И краулер работает не для каких-то определённых сервисов, а для всех, использующих кое-какое семантическое представление. Собирает информацию он также не только о друзьях, а практически всю доступную (данные людей, ссылки на другие их идентификаторы, контакты, ...)
Кроме того, это менеджер сетевых контактов (это не только профили на сервисах, но, к примеру, IM-контакты).
+ аггрегатор событий, с этих контактов с возможностью выбирать, что именно аггрегировать
+ настройка доступа к данным пользователя (к любому элементу данных отдельно, а не вкл/выкл для профиля как это делается обычно)
+ мелочи вроде закладок
Наследование "ромбом" в основном имеет проблемы в компилируемых языках, потому что приходится вводить для него много частных случаев общих в остальном принципов.
Возможно, я непонятно объяснил потому что у меня использование делегирования в указанных вами случаях уже на уровне чувств. Проблемы в случае наследования User от UserSession и UserSettings будут тогда, например, когда вам нужно будет немного изменить логику Userа по работе с настройками, а изменить UserSettings вы не сможете потому что он используется где-то в другом месте. Или наоборот - нужно будет немного изменить UserSettings, а вы не сможете, потому что User слишком много знает о его внутреннем устройстве. Это не проблемы уровня первоначальной реализации - там можно делать практически как угодно. Это проблемы последующей поддержки кода. А, как известно, в нормальных проектах на поддержку тратится куда больше времени и сил чем на первоначальную разработку.
Когда поисковик пишет больше пары тысяч результатов это значит, что на самом деле их может быть сколько угодно. Всё равно он это количество определяет не точно, а какими-то расчётами. И многие поисковики (в том числе гугл) грешат тем, что показывают намного больше, чем могут найти на самом деле.
Насчёт пост-инкремента согласен, но если этот цикл работает не очень много времени я всегда напишу i < count(array) чем перед циклом array_size = count(array) и i < array_size, потому что экономия несущесвенна, а читабельность и время страдает.
О том, почему такого нельзя делать, исписано множество книг по ООП. Наследование (открытое) должно обозначать связь типа "является". Т.е. в вашем случае "User является (подвидом) UserSettings), что неверно. Причин, по которым нельзя в этом случае использовать наследование много. Самая простая - увеличивается связность классов между собой. Впоследствии не получится изменить способ работы с настройками пользователя - он будет жёстко привязан к интерфейсу вашего класса UserSettings, а сессии - к классу UserSession. В этом нет ничего плохого на этапе первоначальной разработки, но если потом пытаться улучшать или модифицировать этот код - проще будет написать новый :)
Вас очень сложно понять.
Если в классе C была создана переменная, нужная классу B - он может её получить без всякого наследования.
Зачем нам нужен один экстенд, а не ноль или два - тоже не понятно, почему А и Б нельзя сделать наследниками С?
Можете привести пример?
Чтобы динамически изменять методы класса уже давно в PHP есть удобный механизм __call. И не нужно извращаться с массивами. И клиент класса не знает о деталях реализации (в отличие от случая с массивами)
Каша какая-то.
Если классу А и классу Б нужен доступ к закрытым методам класса C, то их нужно делать наследниками С, а не наоборот.
Если классу С требуется доступ к закрытым методам А и Б, то у вас, скорее всего, что-то не так с архитектурой.
Второй пример. Вы уж определитесь, что наследуется, закрытые методы или права ACL. Если методы - см. пункт 1, если права - то реализовывать их через отдельные классы глупо.
Подтверждение емейлом мало что решает. Спасает только от самых ленивых троллей, которым лень написать программу для автоматического подтверждения емейла. Кто захочет - создаст себе емейл на одном из сервисов, позволяющих делать себе одноразовые емейлы, изменяя префиксы/суффиксы основного и подтвердить столько аккаунтов сколько захочет.
Кроме того, это менеджер сетевых контактов (это не только профили на сервисах, но, к примеру, IM-контакты).
+ аггрегатор событий, с этих контактов с возможностью выбирать, что именно аггрегировать
+ настройка доступа к данным пользователя (к любому элементу данных отдельно, а не вкл/выкл для профиля как это делается обычно)
+ мелочи вроде закладок
Это пока... )
С bestpersons сравнивать тоже сложно. У нас с ними немного общего. Но проще увидеть, чем услышать.
Возможно, я непонятно объяснил потому что у меня использование делегирования в указанных вами случаях уже на уровне чувств. Проблемы в случае наследования User от UserSession и UserSettings будут тогда, например, когда вам нужно будет немного изменить логику Userа по работе с настройками, а изменить UserSettings вы не сможете потому что он используется где-то в другом месте. Или наоборот - нужно будет немного изменить UserSettings, а вы не сможете, потому что User слишком много знает о его внутреннем устройстве. Это не проблемы уровня первоначальной реализации - там можно делать практически как угодно. Это проблемы последующей поддержки кода. А, как известно, в нормальных проектах на поддержку тратится куда больше времени и сил чем на первоначальную разработку.
А создаёт __call функции или не создаёт - зависит от реализации. Может создавать, может вызывать существующую функцию.
Если в классе C была создана переменная, нужная классу B - он может её получить без всякого наследования.
Зачем нам нужен один экстенд, а не ноль или два - тоже не понятно, почему А и Б нельзя сделать наследниками С?
Можете привести пример?
Если классу А и классу Б нужен доступ к закрытым методам класса C, то их нужно делать наследниками С, а не наоборот.
Если классу С требуется доступ к закрытым методам А и Б, то у вас, скорее всего, что-то не так с архитектурой.
Второй пример. Вы уж определитесь, что наследуется, закрытые методы или права ACL. Если методы - см. пункт 1, если права - то реализовывать их через отдельные классы глупо.
В общем, лучше каптчи ещё ничего не придумали :)