Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 9
Глобальное пространство имен также хранит все внутренние определения PHP, такие как echo()echo — конструкция, с чего бы ей «храниться» в глобальном пространстве?
статья конечно хорошая, но сдается мне лет так на 5 опоздала(5.3.0 вышло в июне 2009). Все то же самое можно прочитать в доках php.net/manual/ru/language.namespaces.php
«Конечно, это по крайней мере хоть какая-то организации, но это очень неэффективно.»
В видении новичков, здесь лишь заменили _ на \ и увеличили использование оперативной памяти для работы с пространством имен.
Прошу пояснить, почему это неэффективно, да к тому же еще и очень? Статья этого не раскрывает.
В видении новичков, здесь лишь заменили _ на \ и увеличили использование оперативной памяти для работы с пространством имен.
Прошу пояснить, почему это неэффективно, да к тому же еще и очень? Статья этого не раскрывает.
Эффективность применения пространства имен здесь не рассматривается со стороны потребления ресурсов (и вряд ли стоит делать это в контексте перевода, ведь это перевод).
Речь идет об организации (как видно из цитаты) и структуре проекта, в котором будут применяться пространства имен.
При разработке даже небольшого проекта я использую Composer, который рекомендует придерживаться стандарта PSR4 (о чем кстати сказано в тексте).
Говоря о проектах которые построены на современных фреймворках, вряд ли можно говорить о применении префиксов.
А если взять в расчет то, что у Вас может быть более 10 подключенных сторонних библиотек, и Вы будете пытаться связать все это руками, да еще и маркируя каждую своим префиксом (делая названия состоящие из 5-8 слов), а плюс вас еще 4 человека на проекте — вряд ли можно говорить об эффективности.
Если говорить о том что классы, расширяющие другие классы или реализующие интерфейсы, должны объявлять свои зависимости на той же строке, а рекомендуемая длина строки в PHP составляет 80 символов, а максимальная длина любой строки PHP-кода не должна превышать 120 символов, то наследование от одного класса и реализация пары интерфейсов заставит Вас нарушить эти правила.
Если у Вас не стоит задача сделать Ваш код читабельным, и Вы не будете в будущем его кому-то показывать, а уж тем более где-нибудь публиковать, Вы вправе выбирать между потреблением ресурсов и «феншуем» кода который Вы пишете.
Речь идет об организации (как видно из цитаты) и структуре проекта, в котором будут применяться пространства имен.
При разработке даже небольшого проекта я использую Composer, который рекомендует придерживаться стандарта PSR4 (о чем кстати сказано в тексте).
Говоря о проектах которые построены на современных фреймворках, вряд ли можно говорить о применении префиксов.
А если взять в расчет то, что у Вас может быть более 10 подключенных сторонних библиотек, и Вы будете пытаться связать все это руками, да еще и маркируя каждую своим префиксом (делая названия состоящие из 5-8 слов), а плюс вас еще 4 человека на проекте — вряд ли можно говорить об эффективности.
Если говорить о том что классы, расширяющие другие классы или реализующие интерфейсы, должны объявлять свои зависимости на той же строке, а рекомендуемая длина строки в PHP составляет 80 символов, а максимальная длина любой строки PHP-кода не должна превышать 120 символов, то наследование от одного класса и реализация пары интерфейсов заставит Вас нарушить эти правила.
Если у Вас не стоит задача сделать Ваш код читабельным, и Вы не будете в будущем его кому-то показывать, а уж тем более где-нибудь публиковать, Вы вправе выбирать между потреблением ресурсов и «феншуем» кода который Вы пишете.
Прочитав
в голове сразу мелькнула мысль о инструменте, кторый пережует легко читаемый код с пространствами имен в оптимизированный с точки зрения потребления ресурсов, на подобие SCSS или LESS.
Если у Вас не стоит задача сделать Ваш код читабельным, и Вы не будете в будущем его кому-то показывать, а уж тем более где-нибудь публиковать, Вы вправе выбирать между потреблением ресурсов и «феншуем» кода который Вы пишете
в голове сразу мелькнула мысль о инструменте, кторый пережует легко читаемый код с пространствами имен в оптимизированный с точки зрения потребления ресурсов, на подобие SCSS или LESS.
На самом деле, основное преимущество пространств имен, на мой взгляд, это их изолированность. Т.е. если вы используете третье-стороннюю библиотеку в которой есть класс с именем, которое уже есть и у вас — без пространств имен будут конфликты, и прийдется один из них переименовывать. А в случае с пространствами имен — они прекрасно уживутся друг с другом.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пространства имен в PHP