Можно так же сказать - если взять портал, работающий под IE, то чтобы переписать его под FF нужно изменить 90% кода :)
И если считать не браузерами, а пользователями, которые на них сидят, цифры будут другими.
На что обратить внимание? Я вам приведу десятки текстов где написано по разному и сам отредактирую википедию.
Главное, не то, что где-то написано, а главное те принципы, которые позволяют программировать объектно-ориентированно, то есть ориентироваться в своем коде на объекты. Сокрытие данных, это дополнительная фишка, местами достаточно удобная, но к самому ООП никакого отношения не имеющая.
Есть отличные ООП-языки, не позволяющие делать сокрытие вообще ни через одно место (например, Python), но это не мешает быть им предельно удобными и мощными в ООП-плане.
Видимо вы превратно понимаете термин "инкапсуляция".
Инкапсуляция, это собрание данных и обрабатывающего их кода в одном месте, а отнюдь, не private-protected-public
А какая связь сессии и авторизации?
Сессия, это конкретный сеанс работы пользователя с сайтом.
Зашел на сайт из кафе - одна сессия. Вышел, пришел домой, зашел снова с другого IP, это уже другая сессия.
Я против сессий ничего и не имею :) И против стандартного механизма так же. Против того, что для 90% задач его хватает, я ничего не говорил. Но, например мне, на 100% задач хватает своего механизма.
Во-первых, это будут мои дыры, в которых я виноват сам, которые я смогу исправить и там где я сам всё контролирую. Как я уже говорил, здесь проблема не столько в возможности существования конкретных дыр, а в том, что не до конца понятно, что и как работает.
Во-вторых, передо мной и зендовцами стоят разные задачи. Мне надо написать оптимальный для моего проекта результат, им универсальный для всех-всех-всех.
При всём моём глубочайшем уважении к компании Зенд, сходите в их багтрекер и посмотрите позволил ли их опыт закрыть все дыры.
Кроме того, дыры очень часто случаются не по вине пхп-разработчиков, а по вине админов серверов.
Да, можно всё настроить (если доступ к php.ini есть), можно сделать надстроку.
Но если всё равно приходится делать настроки, надстройки, навороты и т.п, то зачем оно вообще нужно? Столько же сил потратим, тёмные места всё равно останутся.
На сложных проектах — свой велосипед.
Когда время общей разработки измеряется месяцами, можно потратить полдня на написание и отладку велосипеда и избежать дальнейшего геморроя.
Как PHP всё делает фиг поймешь. Всё складывается в /tmp/, а насколько это безопасно зависит от квалификации админа сервера. Куки пихает со страшным именем, в зависимости от настроек еще может сначала сунуть SID в URL, а может и не сунуть, когда мусор вычистит неизвестно. И так далее и тому подобное.
Кроме того, я храню сессии в базе и могу привязывать к ним другие данные вроде статистики и логов. Со стандартным механизмом так не сделаешь.
И если считать не браузерами, а пользователями, которые на них сидят, цифры будут другими.
Какие стандарты?
Программисты, а банально клаву настроить не могут :)
И чтобы отрисовывающий движок был тоже один.
И браузер был бы один.
Но к чему эти благие пожелания?
Главное, не то, что где-то написано, а главное те принципы, которые позволяют программировать объектно-ориентированно, то есть ориентироваться в своем коде на объекты. Сокрытие данных, это дополнительная фишка, местами достаточно удобная, но к самому ООП никакого отношения не имеющая.
Есть отличные ООП-языки, не позволяющие делать сокрытие вообще ни через одно место (например, Python), но это не мешает быть им предельно удобными и мощными в ООП-плане.
Инкапсуляция, это собрание данных и обрабатывающего их кода в одном месте, а отнюдь, не private-protected-public
Это новый электронный переводчик?
Много лет уже доступен.
И JS2.0 это уже не столько для браузеров язык.
Сессия, это конкретный сеанс работы пользователя с сайтом.
Зашел на сайт из кафе - одна сессия. Вышел, пришел домой, зашел снова с другого IP, это уже другая сессия.
Во-вторых, передо мной и зендовцами стоят разные задачи. Мне надо написать оптимальный для моего проекта результат, им универсальный для всех-всех-всех.
Кроме того, дыры очень часто случаются не по вине пхп-разработчиков, а по вине админов серверов.
Но если всё равно приходится делать настроки, надстройки, навороты и т.п, то зачем оно вообще нужно? Столько же сил потратим, тёмные места всё равно останутся.
Когда время общей разработки измеряется месяцами, можно потратить полдня на написание и отладку велосипеда и избежать дальнейшего геморроя.
Как PHP всё делает фиг поймешь. Всё складывается в /tmp/, а насколько это безопасно зависит от квалификации админа сервера. Куки пихает со страшным именем, в зависимости от настроек еще может сначала сунуть SID в URL, а может и не сунуть, когда мусор вычистит неизвестно. И так далее и тому подобное.
Кроме того, я храню сессии в базе и могу привязывать к ним другие данные вроде статистики и логов. Со стандартным механизмом так не сделаешь.