-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Новости phpStorm
- Автор темы флоппик
- Дата начала
А голосните за http://youtrack.jetbrains.com/issue/WI-17304 плиз. Очень неприятный баг без нормальных воркэраундов.
голоснул!
MiksIr
miksir@home:~$
Что-то не понял, а phpdoc - не решение? Я вот думаю, что они зря изменили поведение для классов с магией, типа незаметно подчеркивают так - расслабляет. Вся магия должна быть описана в пхпдоке.
MiksIr
miksir@home:~$
Не меньше, чем примеры с одним лишь __get в интерфейсе. Сферическому коню сферические решения. Магия, которая делает не известно что - хреновая магия.
Т.е. единственную проблему вижу, когда у нас такой супер-интерфейс супер-хранилища, в котором можно хранить что угодно... говнокод.
Т.е. единственную проблему вижу, когда у нас такой супер-интерфейс супер-хранилища, в котором можно хранить что угодно... говнокод.
В данном случае так нельзя, это то же, что заранее перечислить все возможные ключи массива. Там, где можно - так и делается.
Обрати внимание, что без интерфейса (просто с классом) - все работает. С базовым классом вместо интерфейса - тоже, кстати, работает. Так что это просто банальный баг.
MiksIr
miksir@home:~$
Не так давно работает. Кажется еще в 5.0 было как неопределенное. Мне этот вариант больше нравится. Стараюсь избегать таких ситуаций "как массив". Уж лучше массив и использовать, а преимущества объекта в IDE в подобных случаях как раз минимизация вероятности ошибки.
С массивом не будет автокомплита на методы. Смотри, есть рекурсивный контейнер-накопитель, в котором $container->foo->bar->xxx через __get динамически создает новые вложенные инстансы. В ContainerInterface есть еще ряд методов, они в багрепорте не упомянуты, поскольку не имеют отношения к делу (с ними все хорошо).
Можно писать $container->get('foo')->get('bar')->get('xxx'), это будет правильно работать в PHPStorm, но не хочу.
Можно писать $container->get('foo')->get('bar')->get('xxx'), это будет правильно работать в PHPStorm, но не хочу.
MiksIr
miksir@home:~$
Я бы описал @property foo bar xx
Этому, конечно, не место в интерфейсе, но и PHPдок в описании свойства C мы можем указать не интерфейс, а его реализацию, или несколько реализаций через | которые реально используются. Я бы как-то так делал, меня даже слабо-подчеркнутые свойства "в классе есть магия" настораживают.
Этому, конечно, не место в интерфейсе, но и PHPдок в описании свойства C мы можем указать не интерфейс, а его реализацию, или несколько реализаций через | которые реально используются. Я бы как-то так делал, меня даже слабо-подчеркнутые свойства "в классе есть магия" настораживают.
Чтобы прописать @property, мне придется сгенерить все комбинации от 1 до этак 20 символов. 
Это просто произвольные имена. __get нужен только для эстетики чтобы не писать get()->get()->get().
Уже был реквест про @property <type> * кстати. Но это пофигу, еще раз говорю - обрати внимание на второй пример в багрепорте (это касаемо твоего "указать реализацию"), там все работает.
Тут должен быть именно бледно-серенький про магию (который легко выключить нафиг), а не field not found, о чем тут спорить то =)
Интерфейс указан, потому что у всех реализаций одинаковый интерфейс, и пользователю реализации интерфейса пофигу какая ему реализация интерфейса прилетела. Для этого и нужны интерфейсы, вообще-то.
Это просто произвольные имена. __get нужен только для эстетики чтобы не писать get()->get()->get().Уже был реквест про @property <type> * кстати. Но это пофигу, еще раз говорю - обрати внимание на второй пример в багрепорте (это касаемо твоего "указать реализацию"), там все работает.
Тут должен быть именно бледно-серенький про магию (который легко выключить нафиг), а не field not found, о чем тут спорить то =)
Интерфейс указан, потому что у всех реализаций одинаковый интерфейс, и пользователю реализации интерфейса пофигу какая ему реализация интерфейса прилетела. Для этого и нужны интерфейсы, вообще-то.
MiksIr
miksir@home:~$
Да спорить не буду, что должно иначе ругаться, но задача сама какая-то стремненькая 
Но если пофантазировать, но, наверно, на каждый view был бы класс реализующий этот интерфейс, а в нем уже прописаны пхпдоки.
О, новый реквест созрел - тайпхинтинг на основе всех реализаций интерфейса Или уже есть такое?
Массив использую. А в самом view шаблоне обычно прописываю что туда приходит, да.
Но если пофантазировать, но, наверно, на каждый view был бы класс реализующий этот интерфейс, а в нем уже прописаны пхпдоки.
О, новый реквест созрел - тайпхинтинг на основе всех реализаций интерфейса
Или уже есть такое?Я говорил не о хинте в конструкторе, а именно о пхпдоке, который пишется для людей в общем-то. Если пхпдок не помогает в работе IDE - это хреновый пхпдок