Aggregator резюме программистов

[Вурдалак]

это просто пример чтоб видно было. не понимаю зачем этот суффикс модель или зачем в конкретной модели повторять имя модели при действии.

Ну, конкретно в этом примере — это странно. А вот когда пишут \Foo\User\Repository вместо \Foo\User\UserRepository, то хочется показать этому человеку пять вкладок со словом «Repository» и спросить его: «угадай, какая из них твоя».

 

[WMix]

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

 

[Вурдалак]

Тоже проблемотично, хотя и нэймспэйс подсвечивается в вкладке при одинаковых именах

В том-то и дело, что «User» — это часть имени, не нужно спихивать её в неймспейс.

 

[MiksIr]

У меня даже когда Model\User и Adapter\User - и то иногда случайно лепишь одно вместо другого. А так как неймспейс идет сразу в use да еще и заботливо свернутый штормом - не сразу и заметить можно, что промохнулся в автокомплите. А уж когда начинается использование и того и другого в одном классе - вообще песня, даже тикет шторму пришлось открывать.

 

[grigori]

А ты что, неймспейс руками пишешь? И не импортируешь?

у меня в проекте в легаси-коде шикарное именование классов от любителей все импортировать
import \Model\CatalogMapper\Entity as CatalogMapper;
import \Model\CatalogImage\Entity as CatalogImage;
... 500 строк
$image = new CatalogImage; (класса такого нет - это алиас)
и 5 вкладок в PHPStorm с именем Entity
"счастливой отладки"(С)

 

[Вурдалак]

у меня в проекте в легаси-коде шикарное именование классов от любителей все импортировать
import \Model\CatalogMapper\Entity as CatalogMapper;
import \Model\CatalogImage\Entity as CatalogImage;
... 500 строк
$image = new CatalogImage; (класса такого нет - это алиас)
и 5 вкладок в PHPStorm с именем Entity
"счастливой отладки"(С)

Не очень понятно зачем ты цитируешь меня, рассказывая про свои проблемы

 

[Senseye]

Создал опрос по заполнению информации о владении навыком
Хочу в проекте добавить "опыт по навыку" и на сколько он "применяеться"

 

[fixxxer]

Ну, конкретно в этом примере — это странно. А вот когда пишут \Foo\User\Repository вместо \Foo\User\UserRepository, то хочется показать этому человеку пять вкладок со словом «Repository» и спросить его: «угадай, какая из них твоя».

У меня, кстати, табы вообще выключены в сторме. А по Ctrl-Tab различие видно в таких случаях. (В табах, вроде, тоже такое есть).
А вот Navigate Class (мой основной способ навигации помимо Ctrl-Tab) менее удобен в таком случае, сторму надо подсказывать бекслешом, что речь о неймспейсе (типа Us\R).

 

[флоппик]

У меня, кстати, табы вообще выключены в сторме. А по Ctrl-Tab различие видно в таких случаях. (В табах, вроде, тоже такое есть).
А вот Navigate Class (мой основной способ навигации помимо Ctrl-Tab) менее удобен в таком случае, сторму надо подсказывать бекслешом, что речь о неймспейсе (типа Us\R).

Там есть галка «показывать часть пути для табов с одинаковым именем» кстати

 

[fixxxer]

А уж когда начинается использование и того и другого в одном классе - вообще песня, даже тикет шторму пришлось открывать.

О, а я на эту же тему тикет завел, но это 1-го марта было.
Это, конечно, необычная ситуация, да и делать я так быстро передумал (нашел решение получше), но баг-то все равно баг.
А какие-то еще проблемы на эту тему есть?

 

[Вурдалак]

У меня, кстати, табы вообще выключены в сторме. А по Ctrl-Tab различие видно в таких случаях. (В табах, вроде, тоже такое есть).

Да это всё не заставит меня полюбить такой нейминг, когда значимая часть имени находится в самом неймспейсе. Без которой вообще непонятно о чём идёт речь просто глядя на имя класса: Repository.
Но, например, для событий и команд у меня так и получается, я не используют суффиксы: Acme\Commands\RegisterUser, Acme\Events\UserWasRegistered. Здесь уже из названия видна вся суть, поэтому я напротив одобряю, поскольку не хочу лишний мусор в имени.

Ещё находились умники, которые делали такой нейминг: Foo\Storage\MySql. То есть, класс назывался MySql. Это вообще жесть.

 

[Adelf]

@Вурдалак, по моему нам тут уже пора свой манифест по нэймингу начать формировать. По интерфейсам и абстрактным классам с PSR у нас скорее всего мало кто согласен.

1. Interfaces MUST be suffixed by Interface: e.g. Psr\Foo\BarInterface.
2. Abstract classes MUST be prefixed by Abstract: e.g. Psr\Foo\AbstractBar.

 

[fixxxer]

Да это всё не заставит меня полюбить такой нейминг, когда значимая часть имени находится в самом неймспейсе

Это да, я и сам так редко делаю, но бывают со сторонними библиотеками пересечения, например.

 

[fixxxer]

@Adelf, мне субъективно нравятся интерфейсы с именованием типа Fooable (ну вот, кстати, пхпшные Countable/Serializable), но так мало что получается назвать.

 

[Adelf]

Вурдалак недавно кидал статью http://verraes.net/2013/09/sensible-interfaces/ Там очень советуют -able добавлять только к месту.

 

[Вурдалак]

@Вурдалак, по моему нам тут уже пора свой манифест по нэймингу начать формировать. По интерфейсам и абстрактным классам с PSR у нас скорее всего мало кто согласен.

1. Interfaces MUST be suffixed by Interface: e.g. Psr\Foo\BarInterface.
2. Abstract classes MUST be prefixed by Abstract: e.g. Psr\Foo\AbstractBar.

Да потому что там сидят люди, у которых уже фреймворки имеют такой нейминг и они не хотят что-то менять, у них какая-то закостенелость.
Я как-то видел обсуждение на ML на эту тему, люди пытались протолкнуть suffix-less naming, но в итоге в основном все молча, не вступая в обсуждение, проголосовали против.
Там не единогласно поддерживают этот нейминг.
И вообще у меня особо нет уважения к PHP-FIG, там многие крупные игроки ушли (Doctrine, Laravel, etc.), а пришли какие-то ноунеймы с CMS.

 

[Вурдалак]

@Adelf, мне субъективно нравятся интерфейсы с именованием типа Fooable (ну вот, кстати, пхпшные Countable/Serializable), но так мало что получается назвать.

-able неплох, когда речь идёт о добавлении определенного свойства объекту: Serializable (прилагательное); Но большинство интерфейсов не просто добавляют свойство, они описывают суть объекта (существительное): Logger, UserRepository, etc.

 

[Adelf]

@Вурдалак, т.е. able подходит тем интерфейсам, которые были бы интерфейсами в самом изначальном понимании интерфейсов. А ты привел фактически абстрактные классы, которые мы уже давно стали делать интерфейсами.

 

[Вурдалак]

@Вурдалак, т.е. able подходит тем интерфейсам, которые были бы интерфейсами в самом изначальном понимании интерфейсов.

Я не в курсе что есть «изначальное понимание интерфейсов».

А ты привел фактически абстрактные классы, которые мы уже давно стали делать интерфейсами.

Я не делаю различий, для меня это просто контракт. Проблема, как я уже говорил в другом: невозможность прозрачно поменять абстрактный класс на интерфейс и обратно и невозможность наследовать несколько stateless абстрактных классов в современных языках программирования.

 

[Adelf]

Ну когда еще знакомился с основами ооп были там такие понятия... Т.е. Логгер и репозиторий были бы абстрактными классами, чтобы однозначно определять сущность наследника. Т.е. FileLogger extends Logger implements Serializable - это логгер, умеет он сериализоваться или нет. А по текущим привычкам все делать интерфейсом ктото может сделать MegaUserRepoLogger implements Logger, UserRepository.