или правда include  / mixin

а так вы обманываетесь и думаете, что это часть ООП

ну тогда это не аргумент в разговоре, почему трейты надо или не надо использовать

такой же аргумент как то что банан жёлтый

Для трейтов нет адекватных юзкейсов. Точка

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

С Open close не помогает

потому что точка зрения "мы отказались от трейтов" мне кажется слегка религиозной

бритва оккама)

хотите - используйте
не хотите - не надо

главное не считайте это частью ООП-конструкций языка
всё

У меня есть вроде один или два трейта, просто они не нужны особо

Весьма второстепенная фича

я ровно об этом и говорю
надо - пиши трейты
не надо - ну ОК, меньше конструкций, чище код

просто тут некоторые впадают в фанатизм и начинают крестовый поход

имхо не надо так

можно изи заменить наследованием / копипастой / композицией, но просто переписывать влом

челленджи разнообразят жизнь)

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

Мне кажется что конкретно в этом обсуждении смешиваются разные концепты (компайл тайм, рантайм, позднее связывание, процедурщина и ооп). Просто абсолютно разные вещи

Потому спор в целом ниочем

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

Трейт – это всего лишь возможность вставки фрагментов кода с элементами класса через use в любой класс наравне с физической вставкой фрагментов произвольного кода одного файла через include в другой файл. То есть вещь по сути нейтральная.

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

А трейты, в отличие от классов и интерфейсов, никак в типизации не участвуют. Подтипов не порождают. Свои приватные поля скрывать от класса не могут. То есть используются только для простейшей вставки кода.

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

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

Но если один трейт подключают к нескольким заведомо никак не связанным друг с другом классам, то получается, что код из трейта практически вставляется один в один в каждый класс. Если там есть бизнес-логика, то почему-то оказывается так, что одна и та же логика оказалась нужна нескольким разным классам. Это тревожный сигнал в плане копирования логики и ответственности. Ломается декомпозиция. В этом случае желательно было бы вынести такой повторяющийся код в отдельный объект или чистую функцию.

То есть сам по себе трейт – это вещь нейтральная. А вот копипаста логики уже воспринимается как зло. Поэтому если трейты используют для копипасты логики в нарушение декомпозиции, то получаем, что в этом коде трейтами творят зло. За такую медвежью услугу их и не любят.

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

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

Имхо это прикапывание к мелочам.