Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 78
Не боян-ли?
По-моему лучше в оригинале прочитать - например тут - http://ilia.ws/files/phpquebec_php53.pdf
По-моему лучше в оригинале прочитать - например тут - http://ilia.ws/files/phpquebec_php53.pdf
Спасибо, приятная статья. Многим полезно будет новое узнать.
Один только вопрос - почему на в блоге PHP? Перенесли бы.
Один только вопрос - почему на в блоге PHP? Перенесли бы.
И вопрос в догонку - может автор знает какие-то ньюансы работы с неймспейсами в 5.3 и 6 версии, все-таки лично мне хочется больше уже ньансов, а не простого переписывания того, что написано в принципе везде про появление неймспейсов в новых версиях..
Согласен, вопрос актуальный, но нужно как-то больше конкретики.
Согласен, вопрос актуальный, но нужно как-то больше конкретики.
Мда, чет они перемудрили с двумя двоеточиями. Неужели сложно было придумать новое обозначение? типо >> или три двоеточия)
А разве >> не бинарный сдвиг?
точку надо!! как в нормальных ЯВУ.
зачем? двоеточие на эту роль хорошо подходит, в то же время, неймспейсы - имхо недостаточный повод чтобы вносить в язык новый синтаксический элемент.
Неоднозначности между функцией в неймспейсе и статическим методом, которая приведена в посте, для интерпретатора, на самом деле, не существует - он не позволит вам иметь в пределах одного пространства имет два одинаковых идентификатора. Что же касается удобства для программиста - ну, извиняйте, думать надо как неймспейсы называть это раз....
и два: в чем концептуальная разница между статическим методом и функцией в неймспейсе, а? (-:
А, ну и ещё: в питоне, например, для обращения к методам объектов и к объектам из ругого пространства имён тоже используется одинаковый синтаксис (точка) и ничего, никто пока не умер (-:
Неоднозначности между функцией в неймспейсе и статическим методом, которая приведена в посте, для интерпретатора, на самом деле, не существует - он не позволит вам иметь в пределах одного пространства имет два одинаковых идентификатора. Что же касается удобства для программиста - ну, извиняйте, думать надо как неймспейсы называть это раз....
и два: в чем концептуальная разница между статическим методом и функцией в неймспейсе, а? (-:
А, ну и ещё: в питоне, например, для обращения к методам объектов и к объектам из ругого пространства имён тоже используется одинаковый синтаксис (точка) и ничего, никто пока не умер (-:
Метод связан с классом или объектом, тогда как функция от объекта не зависит
http://en.wikipedia.org/wiki/Method_(computer_science)
http://en.wikipedia.org/wiki/Function_(computer_science)
http://en.wikipedia.org/wiki/Method_(computer_science)
http://en.wikipedia.org/wiki/Function_(computer_science)
не-не. я спрашивал конкретно про статические методы.
с точки зрения вызывающего в чем разница?
насколько важно мне знать чем концептуально отличаются класс C и неймспейс N в этих примерах:
C::get_instance();
N::get_instance();
с точки зрения вызывающего в чем разница?
насколько важно мне знать чем концептуально отличаются класс C и неймспейс N в этих примерах:
C::get_instance();
N::get_instance();
self
как я понимаю, в неймспейсах он не доступен
как я понимаю, в неймспейсах он не доступен
1. В статичных методах при наследовании насколько я помню можно обращаться к родительским методам через parent::метод
2. Обращение к статичным параметрам класса (правда с наследием там вроде баги были)
Как я понимаю c namespace такого не проделаешь, хотя выглядит оно одинаково и вероятно реализуется тоже.
2. Обращение к статичным параметрам класса (правда с наследием там вроде баги были)
Как я понимаю c namespace такого не проделаешь, хотя выглядит оно одинаково и вероятно реализуется тоже.
Это преемственность С++
в C++ такая же неоднозначность существует. И ничего, живут.
интересно, когда версии с поддержкой неймспейсов станут распространены на различных хостингах, имена классов в Zend Framework остануться такими же, или все переведут на неймспейсы...
require_once — моветон в php 5+, есть SPL. А так ниче нового не сказали, анонс namespace был давно.
Вы имеете ввиду autoload? Помоему он тоже require_once использует.
Он использует то, что напишет программист. __autoload() - это просто функция, а не магия какая-то :)
function __autoload($className) {
$fileName = $className.'.class.php';
require PATH_ROOT."classes/".$fileName;
}
Простейший пример.
function __autoload($className) {
$fileName = $className.'.class.php';
require PATH_ROOT."classes/".$fileName;
}
Простейший пример.
Я такую конструкцию и использую, вот и интересуюсь - можно ли и как попроще (и куда уж проще)?
Тогда я не совсем понял, что значит "Вы имеете ввиду autoload? Помоему он тоже require_once использует. ".
Ответ на Ваш вопрос - "а куда еще проще?".
Ответ на Ваш вопрос - "а куда еще проще?".
Я не складирую все файлы в одну папку если вы подразумеваете autoload по умолчанию
Ну на самом деле я не подразумевал, у меня как раз в разных папках.
Я делаю это приблизительно так:
function __autoload($className) {
$locations = array('forum', 'fun', 'gallery', 'leecher', 'soap', 'common');
$fileName = $className.'.class.php';
foreach ($locations as $path) {
if (file_exists(PORTAL_PATH_ROOT."classes/".$path."/".$fileName)) {
require PATH_ROOT."classes/".$path."/".$fileName;
break;
}
}
}
Вы же можете массив сделать в конфиге или из базы выбирать, в зависимости от того, как храните информацию о модулях.
Я делаю это приблизительно так:
function __autoload($className) {
$locations = array('forum', 'fun', 'gallery', 'leecher', 'soap', 'common');
$fileName = $className.'.class.php';
foreach ($locations as $path) {
if (file_exists(PORTAL_PATH_ROOT."classes/".$path."/".$fileName)) {
require PATH_ROOT."classes/".$path."/".$fileName;
break;
}
}
}
Вы же можете массив сделать в конфиге или из базы выбирать, в зависимости от того, как храните информацию о модулях.
PORTAL_PATH_ROOT = PATH_ROOT - плохо отредактировал.
Видите - всё правильно, вы тоже require используете, а что Xobb имел ввиду я не понимаю..
Я имею ввиду SPL-register. Оно позволяет написать правило загрузки классов. Наглядный пример здесь. Да, в принципе используется require, но только один раз и больше его в коде использовать не надо. Своим комментарием я имел ввиду, что если мы уж настолько продвинуты чтобы использовать namespace то было б хорошо научится и делать autoload.
Спасибо за информацию! Давно пишу на php, а про эту фичу не знал. Буду разбираться, надоело писать в стиле php4
По поводу spl_autoload_register, я его использовал одно время, но потом отказался в пользу статичного(единственного) автолоада с проверками дирректорий и наличия файлов, поскольку динамическая регистрация уж очень много ресурсов жрет.
Не понимаю, чем require плох. Да, автолоад, несомненно, рулит, но, имхо, это какая-то глупая религия - сокращать количество require до 1 в проекте... Конечно, 500 require это тоже перебор, но autoload так или иначе выполняет столько же require(достаточно глянуть по профайлеру), хоть они и сосредоточены в одном методе.
Все просто - уменьшение сложности. Тебе не надо задумыватся о том как подключать, где и по какому принципу классы, ты решаешь это все зарание и больше не задумываешься.
Хм, тут такие хитрые коды пишут, лишь бы не писать лишние require... Может я читаю как-то не так, но мне кажется, что слишком категорично высказано, что на весь проект должен быть 1 require и тот в автолоаде... Я и сам активно юзаю autoload, но не вижу смысла сокращать количество require до 1-2, имхо, разумный предел - 5-10, хотя всё зависит от архитектуры проекта.
А разве исполнение php-файлов ограничивается только подключением классов?
Простите меня пожалуйста, вы сноб и приебываетесь.
Мое мнение относится только к коду выше. И никуда больше. Да, я сам использую require, когда мне надо подключить левый код к своему проекту, который не следует API фреймворка, на котором я работаю.
require_once('mycms/core.php');
use MyCMS::Core::System; //импортируем только заданный класс
$objSystem=new System;Мое мнение относится только к коду выше. И никуда больше. Да, я сам использую require, когда мне надо подключить левый код к своему проекту, который не следует API фреймворка, на котором я работаю.
Да ну..для классов уже давно используется __autoload, а если пишут на функциях все, то кто уж им виноват..
Хм, почему моветон?
посмотрите мой комментарий.
require_once('mycms/core.php');
use MyCMS::Core::System; //импортируем только заданный класс
А разве require_once не "импортировало" уже все то, что было в mycms/core.php?
use MyCMS::Core::System; //импортируем только заданный класс
А разве require_once не "импортировало" уже все то, что было в mycms/core.php?
use автоподстановку делает.
Как я понимаю, new Class() будет на самом деле делать new MyCMS::Core::System::Class()...
Имхо, бесполезная штука — нагляднее использовать полное название неймспейса или хотя бы алиас...
Как я понимаю, new Class() будет на самом деле делать new MyCMS::Core::System::Class()...
Имхо, бесполезная штука — нагляднее использовать полное название неймспейса или хотя бы алиас...
во всех языках сделали такую бесполезную штуку. вот глупцы.
Хотелось бы, например, знать
- как можно в автолоаде узнать запрашиваемый неймспейс или как можно (и можно ли) делать локальные (в рамках одного неймспейса) автолоады
- можно ли перемещаться по иерархии неймспейсов? потому как если нет, то лучше было бы сделать вложенные классы для static обращений
- как понять фразу мануала «К примеру, если пространство имён A::B::C импортировано, new C() будет транслировано как new A::B::C().», если new A::B::C() обращается к неймспейсу A::B
Хороший язык - php, сейчас правда перешел с него на Java и уже плотно занимаюсь только ею, но такое чувство что концептуально (т.е. за исключением некоторых моментов синтаксиса и конечно же рантайма) между ними скоро не будет различий ;)
пространства имен штука очень полезная. Но, как это обычно бывает у разработчиков PHP, хотели как лучше - получилось как всегда: какой то корявый синтаксис System::Core. А ведь можно было сделать очень просто и красиво:
namespase System.Core
{
class MyClass()
{}
}
к сожалению, точка уже давно забита под конкатенацию строк :(
уверяю, нет никакой технической проблемы, что точка конкатенирует строки. На месте имени нэймспэйса же не expression.
А в принципе точка как конкатенация строки — бред полный, плюс куда лучше был бы.
А в принципе точка как конкатенация строки — бред полный, плюс куда лучше был бы.
ну в общем, дело не в точке, а в единообразности - содержимое класса находится между фигурными скобками{}, так почему же сам класс не поместить в пространство имен между {}.
Постепенно php превращается в perl. Это не может не радовать. Так глядишь и оператор =~ появится вместно ужасных preg_*
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пространство имён в php 5.3 и php 6