Алексей Анатольевич
Или симфони теперь по дефолту будет "уведомлять" меня о всех своих deprecated при каждой попытке очистить кеш
Konstantin
там написано, примерно дословно
Konstantin
"с версии такой-то НЕ УСТАНОВКА этого значения депрекейтед. с версии 6.0 будет трактоваться как тру"
Konstantin
не понимаю, люди, как вы докатились до симфони, если у вас такие проблемы возникают
Юра
)
Юра
Надо встроить гугл переводчик в терминал
Konstantin
да зачем людей насиловать, для них 1с есть
Алексей Анатольевич
сам то понял что перевел
Юра
Или симфони теперь по дефолту будет "уведомлять" меня о всех своих deprecated при каждой попытке очистить кеш
Ты можешь изменить то что там написано, чтобы пропало сообщения. Сделаешь переход на новые версии проще
Алексей Анатольевич
тупо бред несвязный
Алексей Анатольевич
короче я обновил компосером, ошибка отпала
Алексей Анатольевич
Ты можешь изменить то что там написано, чтобы пропало сообщения. Сделаешь переход на новые версии проще
видимо да, компосер обновил версию бандла и все стало как должно быть
Юра
Там написано что если ты эту опцию не установишь руками, в шестой версии будет по дефолту true
Юра
А раньше наверное было false
Алексей Анатольевич
Спасибо! Теперь хотя бы буду знать..
l0gic
Vladimir
Vladimir
ну ошибся человек, может, пьяный писал, или переработал. ты у него спроси, что он имел в виду. если такое повторится - говори с вышестоящим начальством. это и есть софт скиллы, а ты сразу издеваться)
Ivan
nullable true, но при этом переменная не может быть null? Да и каскадное удаление явно лишнее
Сергей
типа при удалении сущности, удалится юзер?)))
Видимо речь о том, что крейтедбай сделал стрингой
Ivan
Косяк у обоих, переведите на третьего разработчика
Юра
Хз как по мне надо всех уволить и закрыть фирму
Павел
Павел
Если так по всей системе - то надо обсуждать рефакторинг и новый путь, а не лепить в одну калитку МР своё виденье. Но в целом это ок.
Shokha
Добрый день)
Doctrine был такой метод что можно сетит relation без обекта а только с ID связи!
как назвалось это метод напомните пж
Vlad
getReference
Задорный Копатыч
Доброго времени суток.
interface Inter
{
}
abstract class A
{
abstract public function call(Inter $i);
}
class InterObj implements Inter
{
}
class B extends A
{
public function call(InterObj $i) // <- Естественно, нарушает LSP
{
}
}
Подскажите, как лучше выйти из ситуации? Есть базовый класс, есть наследники. Работать они должны с конкретными реализациями интерфейса, а не базовым.
Vlad
generic
Задорный Копатыч
Что генерик. В доксидоках?
Задорный Копатыч
Вскод поди обосрется с хелпингом.
Vlad
https://phpstan.org/blog/generics-in-php-using-phpdocs
Задорный Копатыч
https://phpstan.org/blog/generics-in-php-using-phpdocs
Спасибо. Можно попробовать. Lsp все равно ломается, судя по всему.
Но, тут особый случай.
Елнур
Доброго времени суток.
interface Inter
{
}
abstract class A
{
abstract public function call(Inter $i);
}
class InterObj implements Inter
{
}
class B extends A
{
public function call(InterObj $i) // <- Естественно, нарушает LSP
{
}
}
Подскажите, как лучше выйти из ситуации? Есть базовый класс, есть наследники. Работать они должны с конкретными реализациями интерфейса, а не базовым.
Внутри функции call, в классе B
assert($i instanceof InterObj);
Павел
Вариант выше, или instance OF или уйти от наследования.
Задорный Копатыч
Вариант выше, или instance OF или уйти от наследования.
Уходить не хотелось бы. Это tagged iterator.
Павел
Уходить не хотелось бы. Это tagged iterator.
Ну тогда вам надо просто решить, что должны делать ваши классы, если им подсунули не ту реализацию. Упасть или пропустить и ничего не делать.
Павел
Ну и LSP тут вроде не ломается. То что ваш класс работает не со всеми реализациями, не значит что это ломает LSP. Но это не точно )
Задорный Копатыч
Ну, php как бы сам пишет, что поломато. Самый первый пример кода - вообще не валиден.
Павел
Ну, php как бы сам пишет, что поломато. Самый первый пример кода - вообще не валиден.
Вы ставите конкретный класс, а надо ставить интерфейс
Павел
а отсекать лишнее в коде
Павел
через assert или instanse of
Konstantin
вам не нужно наследование, ваш call не работает с InterObj
Konstantin
вы пишете "вот в этот метод можно сунуть инстанс интерфейса", а потом фактически говорите "нет, не весь, а конкретный класс". тут нужно описать женерик T extends InterObj
Konstantin
но я бы советовал не морочить голову и ничего не писать :) это сервисный код, существующий только в момент компиляции контейнера, там уж можно обойтись без типобезопасности
Konstantin
обложиться ассертами/инстансоф-ами
Konstantin
если я правильно понял про тегированый итератор
Задорный Копатыч
вы пишете "вот в этот метод можно сунуть инстанс интерфейса", а потом фактически говорите "нет, не весь, а конкретный класс". тут нужно описать женерик T extends InterObj
Ну я в целом так и сделал. Это некрокод, который я из свитча на 50 кейсов попытался разбить на инстансы.
И в 50% там интерфейса достаточно, но для оставшихся интерфейс расширялся доп. методами.
Задорный Копатыч
Поэтому "отпусти и забудь". Некрокод остается некрокодом, а новые инстансы по интерфейсу уже только.
Konstantin
чтобы вскод подставлял, можно оставить в сигнатуре интерфейс, но написать пхпдок @param про конкретный класс
Задорный Копатыч
Я его немного иначе обманул.
class Necrocode {
public function call(Interface $i) {
// Тут еще ассерты
$this->realCall($i);
}
public function realCall(Object $o) {
}
}
Nikolay
Вопрос по code style. Есть правила для php cs fixer, стандартное правило Symfony использует yoda_style. Кто как считает, целесообразно ли использовать его? Странно, что в symfony есть такое правило
Konstantin
они любят писать if (null == $foo = getFoo())
Konstantin
вероятно оттуда торчит, во всех остальных местах они вроде бы нормально ифы пишут
Konstantin
стоит ли так писать - вопрос риторический, я лично пишу (но только ифы с присваиванием короткого выражения), писать ли вам - сами решайте
Nikolay
стоит ли так писать - вопрос риторический, я лично пишу (но только ифы с присваиванием короткого выражения), писать ли вам - сами решайте
Я бы не писал, но на проекте считают по другому. Есть ли какое нибудь правило для фиксера, которое запрещает присваивание в условиях?
Konstantin
не готов ответить, наверняка есть
Александр II
Добрый
подскажите пжл как более правильно это реализовать
есть несколько справочников (допустим 4). Есть общие поля в этих справочниках.
Я конечно могу создать 4 класса и продублировать все в каждом классе
либо
1 - создать трейт с общими полями
2 - создать общий обычный класс и наследоваться от него
но при этом, как будет выглядить фабрика?
return (new ClassA(
id: $dto->getId()
name: $dto->getName()
))->setDate($dto->getDate);
на сколько это правильно?
Konstantin
общие поля != повод для наследования
Konstantin
если у компании и юзера, например, есть поля id и name, надо ли их наследовать от общего предка?
Александр II
ну тут имеется ввиду общее
это справочники
у них общие id, name, code, title
Александр II
т.е. правильнее в каждом классе описать?
Konstantin
и второй вариант плох тем, что объект допускает свое невалидное состояние. можно не позвать setDate и вместо объекта будет шлак
Konstantin
поэтому лучше все что можно инициализировать в конструкторе, без сеттеров
Александр II
хорошо, спасибо
Konstantin
в целом если можно не наследовать (особенно всякие дата-классы) - лучше не наследовать
Александр II
А вообще хотел спросить
может есть у кого проектики, к кому могу присоедениться, мне самое главное интересные задачи и опыт, менторство
Spider
Аналогиично - тоже ищу задачи опыт и наставника - если возможно
Юра
ANDREW
Здравствуйте. Есть большой опыт с PHP, понимание и работа в команде. Но все проекты это легаси код и симфони 1.4
Хотелось бы найти наставника и быть полезным проекту на современном симфони. Готов рассмотреть любые вакансии даже без оплаты и в дальнейшем с трудоустройством в компании, если увидят мой прогресс. Учусь и вникаю в код быстро.
Jonny
Здравствуйте. Есть большой опыт с PHP, понимание и работа в команде. Но все проекты это легаси код и симфони 1.4
Хотелось бы найти наставника и быть полезным проекту на современном симфони. Готов рассмотреть любые вакансии даже без оплаты и в дальнейшем с трудоустройством в компании, если увидят мой прогресс. Учусь и вникаю в код быстро.
Если есть время и возможность, сделай пет проект чтобы показывать код
Всяко лучше чем просто слова
ANDREW
Если есть время и возможность, сделай пет проект чтобы показывать код
Всяко лучше чем просто слова
Кода много, в основном PHP 5.6, последние пару лет с 7.4 но в основном проекты были создание API. Практика есть, нет еще понимания грамотной архитектуры. Потому и рассматриваю себя как подмастерье, готовый учиться и помогать без оплаты и в дальнейшем остаться в команде и быть полезным
Nikolay
Юра
Просто возьми api platform. Там сложно написать неграмотное апи
Юра
Медленное легко )
Gleb
Кода много, в основном PHP 5.6, последние пару лет с 7.4 но в основном проекты были создание API. Практика есть, нет еще понимания грамотной архитектуры. Потому и рассматриваю себя как подмастерье, готовый учиться и помогать без оплаты и в дальнейшем остаться в команде и быть полезным
Сам с середины прошлого года пытаюсь вкатиться в симфони с примерно такой же базы, около 5 лет своих проектов, год в ком.разработке, пхп был преимущественно старый.
стажировка на симфони, равно как и позиции джуна очень редки. Лучше пилить свой пет проект для демонстрации, может отдавать кому-то на ревью, перепиливать и потом показывать на позиции.
А в целом лучше потусить годик-другой в другом стеке, не симфони. Потому что куда с таким опытом возьмут, это в основном легаси Симфа 3, иногда 4.
На толковые проекты там от 3-5 лет ком.опыта, понимание архитектуры и умение писать норм ооп, ну и естественно знание фреймворка по частям и основных бандлов.
Gleb
Естественно это не догма, а личные наблюдения с июля прошлого года. Сам пока ушёл тусить в другой фреймворк и учу симфони, пилю петы.
ANDREW
Спасибо за советы. Сейчас есть много свободного времени. Пилить свое изначально с непониманием архитектуры конечно нет смысла. Но видимо так и прийдется делать