Стандарт PSR-0

[ShafMAN]

Здравствуйте
У меня вопрос по стандарту PSR-0 .

Допустим у нас следующая структура:

\Zend\Mail\Message => /path/to/project/lib/vendor/Zend/Mail/Message.php

Значит имя класса в Message.php будет Message:

class Message
{
    // code
}

Второй вариант:

\namespace\package\Class_Name => /path/to/project/lib/vendor/namespace/package/Class/Name.php

Здесь в файле Name.php имя класса получается должно быть Class_Name :

class Class_Name
{
    // code
}

Т.е. во втором варианте у нас название класса не совпадает с именем файла. Подскажите я вообще правильно понял, так и должно быть?

 

[WMix]

2й вариант правильный... да имя класса не совпвдает с именем файла
но
файл класса Zend_Mail_Message можно легко найти по алгоритму

include( str_replace('_','/',$className).'.php' );

 

[ShafMAN]

Первый вариант тоже правильный. Вы наверное по указанной ссылке не прошли (ссылка)

Как я понял в вашем варианте путь к файлу содержится в имени класса. В PSR-0 используется пространство имён (namespace).

 

[fixxxer]

Оба варианта правильные, надо исходить из принципа наименьшей помойки в каждом частном случае

 

[ShafMAN]

Все равно с этими стандартами PSR как-то запутано в наименовани классов.

Если по второму варианту PSR-0 позволяет именовать классы как Class_Name, то в PSR-1 пишется что нужно именовать классы как ClassName. (ссылка PSR-1)

 

[AmdY]

ShafMAN
подчёркивание это стиль до php 5.3, используя неймспейсы его использовать нежелательно.

 

[ShafMAN]

Т.е. если взять первое моё сообщение, то в PHP 5.3 и выше нужно использовать первый вариант а не второй?

 

[A1x]

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

 

[fixxxer]

Нужно-нужно, мало ли кто где что написал.

Возьмем для примеру Twig. Завертывается все в namespace Twig, убирается префикс твиг у класса ОК.

Теперь у нас есть, ммм, Twig_Node_Expression_Binary_Greater, это что, предлагается вот это все завертывать в неймспейсы? Лол, кто-то не понимает что такое неймспейс тогда.

Хорошо, можно сказать - не, просто класс будет Twig \ NodeExpressionBinaryGreater. Ну ок, как тогда должен работать автолоадер?

 

[A1x]

ну вот в ZF2 просто все поддиректории перевели в неймспейсы - было Zend_Mail_Protocol_Smtp_Auth_Login

стало

namespace Zend\Mail\Protocol\Smtp\Auth;
use Zend\Mail\Protocol\Smtp;

class Login extends Smtp

насколько я понял, стандартному PSR-0 автолоадеру все равно что грузить классы в стиле ZF1
что с неймспейсами как с подчеркиваниями так и без подчеркиваний в именах классов

 

[fixxxer]

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

В случае с Zend_Mail я усматриваю \Zend и \Zend\Mail. (то есть vendor и vendor\product). Все дальше явно не неймспейсы. Просто все устали от Foo_Bar_Bazz_Aaaa_Thats_So_Fucking_Long_Class_Name и с появлением неймспейсов на радостях ударились в другую крайность =)

 

[A1x]

не спорю, уродство
ну тогда остается Zend\Mail\ProtocolSmtpAuthLogin или Zend\Mail\Protocol_Smtp_Auth_Login

что мне кажется еще большее уродство
по крайней мере в ZF2 пошли по самому легкому пути, который к тому же соответствует общепринятой практике
когда иерархия директорий, в которой хранятся исходники классов, соответствует иерархии пакетов/неймспейсов этих классов.

 

[fixxxer]

ну тогда остается Zend\Mail\ProtocolSmtpAuthLogin или Zend\Mail\Protocol_Smtp_Auth_Login

что мне кажется еще большее уродство

Почему? Все нормально. Неймспейсы вводим там, где они действительно нужны (и где префиксы типа Zend_Mail использовались для эмуляции), дальше оставляем как было.
Учитывая то, что писать будем обычно не Zend\Mail\Protocol_Smtp_Auth_Login а так

- внутри

namespace Zend\Mail;
class Protocol_Smtp_Auth_Login {
}

- снаружи

namespace MyVendor\MyProject;
use Zend\Mail;

class MyClass {
    public function initMailer() {
        $Transport = new Transport_Smtp($this->config->get('mail.smtpServer'));
        $this->Mailer = (new Mailer)->setTransport($Transport);
    }
}

все будет отлично.

Варианты типа Zend\Mail\ProtocolSmtpAuthLogin смотрятся вроде бы лучше, но потом захочется раскладывать по папочкам, появится автолоад с перебиралкой вариантов и кэшированием (либо сканер и генератор)... Проходили, это ад и жесть, лучше иметь автолоадер тупым (с заменой \ и _ на /) и всегда понимать где что лежит с первого взгляда.

 

[A1x]

Неймспейсы вводим там, где они действительно нужны

вот это "действительно нужны" конечно очень условно

В случае с Zend_Mail я усматриваю \Zend и \Zend\Mail. (то есть vendor и vendor\product). Все дальше явно не неймспейсы.

теперь появляется новая проблема решать где "еще неймспейсы" а где "уже явно не неймспейсы"
так как мне не нравятся подчеркивания в именах классов, то мне больше нравится подход ZF2 -)

 

[Вурдалак]

- снаружи

use Zend\Mail\Transport_Smtp;
use Zend\Mail\Mailer;

 

[fixxxer]

А где Transport_Interface тогда?

 

[fixxxer]

теперь появляется новая проблема решать где "еще неймспейсы" а где "уже явно не неймспейсы"

Неймспейсы там, где можно импортнуть _только_ его (плюс что-то совсем базовое выше уровнем, типа ядра фреймворка - то что импортим ваще в любом случае) и полноценно использовать то, что импортнулось. Иначе это просто замена одной загогулины на другую

 

[A1x]

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

 

[Вурдалак]

А где Transport_Interface тогда?

Да ты о чем? Если ты пишешь просто

use Zend\Mail;

, то тебе придется писать

class MyClass {
    public function initMailer() {
        $Transport = new Mail\Transport_Smtp($this->config->get('mail.smtpServer'));
        $this->Mailer = (new Mail\Mailer)->setTransport($Transport);
    }
}