Расширение класса внешними методами и переменными

[Yoskaldyr]

@grigori насчет большого количества расширений было в соседней теме.
А насчет красной красной тряпки - это же правда. Народ почти всегда читает по диагонали и только замечает триггеры начинает агрится. И это норма во всех сообществах!
Я меня, тоже нелюбовь к наследованию когда все классы в какой либо поделке отнаследованы от одного класса Main (рефакторить такое ооочень "приятно"), вместо того чтобы реализовать интерфейс + использовать трейты для повторяющего кода. Но с другой стороны понятно - иногда поделки живут десятилетиями еще с пхп 5.2 и лень или банальное отсутствие времени или ума (или того и другого - мне некогда, мне лес валить надо!!!) мешают переписыванию.

из статьи по ссылке я вижу то же самое, что сделано в yii

?

 

[grigori]

Вы оба два не тот язык выбрали.
Берите Ruby с его include-ами.
В тех же Рельсах все живет на миксинах и прочем манкипатчинге, все как вы любите.

и сократить количество потенциальных клиентов/проектов в 25 раз

я думаю так: статистически более 80% сайтов в мире написаны с Java-моделью ООП или процедурно - без mixin, duck typing и множественного наследования, и этого достаточно, чтобы утверждать, что обсуждаемой проблемы в реальности не существует;
ребята или обсуждают абстрактного коня в вакууме, или нашли фатальный недостаток, или тут пишут одно, а в реальности задача совсем другая

 

[grigori]

@grigori насчет большого количества расширений было в соседней теме.
А насчет красной красной тряпки - это же правда. Народ почти всегда читает по диагонали и только замечает триггеры начинает агрится. И это норма во всех сообществах!
Я меня, тоже нелюбовь к наследованию когда все классы в какой либо поделке отнаследованы от одного класса Main (рефакторить такое ооочень "приятно"), вместо того чтобы реализовать интерфейс + использовать трейты для повторяющего кода. Но с другой стороны понятно - иногда поделки живут десятилетиями еще с пхп 5.2 и лень или банальное отсутствие времени или ума (или того и другого - мне некогда, мне лес валить надо!!!) мешают переписыванию.

1. иерархия наследования служебных классов фреймвока никому не мешает,
мешает бессмысленное наследование - в частности, твой пример нарушения принципа Лисковой
2. красная тряпка не на наследование - никто не против одного из трех главных слов в нашей жизни, красная тряпка у всех на желание есть суп вилкой
3. мы читаем буквально, а за фразу "я в другом топике писал" можно снести тему в мусорку и закрыть - это прямое нарушение пункта правил форума
4. трейты не лучше наследования, это одна из его форм, и проблем с трейтами ничуть не меньше
5. кодогенерация заканчивается с preloading, jit и неблокирующей обработкой, тема застряла в технологиях 10-летней давности
6. переписанный код обычно хуже, чем изначальная поделка

 

[grigori]

Что-то не помню чтобы в yii были промежуточные прокси классы при наследовании... Может пропустил, можно ссылку на код?

в yii есть BaseActiveRecord, и есть его наследник - промежуточный класс ActiveRecrd,
чтобы удобнее заменить некоторые методы в ActiveRecord, отнаследовав свой userland-класс от другого потомка,
но надо учитывать, что этому дизайну более 10 лет, и причин так делать давно нет

Самая главная проблема готового продукта, что в принципе нельзя предусмотреть где конечному пользователю понадобятся точки расширения.

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

 

[fixxxer]

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

Можно, но типизировать придется, иначе не скомпилируется.
Вообще ни разу так не делал, это все же извращение. Я им когда-то давно (во времена 0.9.x) предлагал концепцию compile time трейтов а-ля scala, на архитектуру их компилятора ложилось влет, но они не захотели делать что-то, слишком уж отличающееся от ecmascript. (Они тогда даже await делать не хотели, потому что без страшной кодогенерации state machine не скомпилишь, а там была идея, что скомпилированный js должен быть читабельным, как будто это кому-то нужно, со временем, конечно, до них дошло, что всем пофиг).

и сократить количество потенциальных клиентов/проектов в 25 раз

Вообще я подозреваю, что добрые 90% там - это вордпрессы и прочие друпалы с джумлами. В докере-то кому какая разница что запускается? А коробочный продукт - это уже скорее образ для докера, чем пачка говна, которую заливают по ftp на шаред. Сейчас, может, не совсем, но лет через 5 так точно.

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

 

[Yoskaldyr]

в yii есть BaseActiveRecord, и есть его наследник - промежуточный класс ActiveRecrd,
чтобы удобнее заменить некоторые методы в ActiveRecord, отнаследовав свой userland-класс от другого потомка,

Так это пример плохой архитектуры - наследование ради наследования, которое понятное дело, в современных реалиях делать не надо.
А здесь в теме как раз было упомянуто немного другое. Классы дополнений расширяют виртуальные классы, не существующие при написании кода, они есть только в момент рантайма и что это будет за класс решает контейнер и реализует его через class_alias. Это вообще не одно и то же когда вся цепочка известна заранее.
Вот еще раз немного кода для сравнения:

//yii я интерфейсы и т.п. убрал чтобы только цепочку было видно
//все эти классы известны при написании кода 
//и эта цепочка никак не зависит от конфигурации приложения
class ActiveRecord extends BaseActiveRecord  {}
class BaseActiveRecord extends Model {}
class Model extends Component {}
class Component extends BaseObject {}
class BaseObject {}

// это полностью неизменная цепочка:
//  ActiveRecord -> BaseActiveRecord  -> Model -> Component -> BaseObject



//---------------------------------
//динамическое наследование
//только эти классы известны при написании кода
class AddOn1Base extends AddOn1Base_VirtualProxy {}
class AddOn2Base extends AddOn2Base_VirtualProxy {}
class Base {}
// в рантайме может быть вызвано (а может быть и нет, все зависит от рантайм конфигурации):
class_alias('Base', 'AddOn2Base_VirtualProxy');
class_alias('AddOn2Base', 'AddOn1Base_VirtualProxy');

//это в рантайме сгенерирует цепочку (алисы)
//AddOn1Base -> AddOn1Base_VirtualProxy (алиас AddOn2Base) -> AddOn2Base_VirtualProxy (алиас Base)

//если алиасы вызваны по другому может быть другая цепочка (другой порядок включения дополнений)
class_alias('Base', 'AddOn1Base_VirtualProxy');
class_alias('AddOn1Base', 'AddOn2Base_VirtualProxy');

//это в рантайме сгенерирует цепочку (алисы)
//AddOn2Base -> AddOn2Base_VirtualProxy (алиас AddOn1Base) -> AddOn1Base_VirtualProxy (алиас Base)

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

Можно, но типизировать придется, иначе не скомпилируется.

Так это же хорошо, меньше шансов нарушить контракт

 

[fixxxer]

5. кодогенерация заканчивается с preloading, jit и неблокирующей обработкой, тема застряла в технологиях 10-летней давности

Ммм, а если через php filter реврайтить код, то по идее закэшируется (и - поскольку JIT делается как часть opcache - и скомпилируется) отреврайченный.
Хотя это в топик про извращения надо.

 

[Yoskaldyr]

@fixxxer php filter не кешируется опкод кешем

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

я вообще это не применяю при нормальной разработке.

Но вот как реализовать для коробочного продукта.
Клиент купил продукт установил или заплатил за установку. А потом в админке оплатил и повключал кучу расширений, расширения сами скачались и установились.
Сейчас пользователи ленивые после аппсторов на мобильниках и легкая установка и настройка очень важна для пользователя.
Расширения могут менять вообще как угодно базовый код. Все предложенные выше варианты, кроме извращения с динамическим наследованием, не решают основного бизнес требования - максимальная гибкость модификации сторонними дополнениями основного кода.

 

[grigori]

Вообще я подозреваю, что добрые 90% там - это вордпрессы и прочие друпалы с джумлами. В докере-то кому какая разница что запускается? А коробочный продукт - это уже скорее образ для докера, чем пачка говна, которую заливают по ftp на шаред. Сейчас, может, не совсем, но лет через 5 так точно.

разве мы обсуждаем не xenforo на шаредах с плагинами от wordpress?

Ммм, а если через php filter реврайтить код, то по идее закэшируется (и - поскольку JIT делается как часть opcache - и скомпилируется) отреврайченный.
Хотя это в топик про извращения надо.

обрадуй Диму )))

 

[grigori]

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

Апстор - отличный пример именно бизнеса. Guidelines. Публиковал когда-нибудь аппликуху в сторе? Там любой код не примут.
Не надо про бизнес-требования, ничего подобного у бизнеса в требованиях не бывает, у бизнеса критерии правильные, в отличие от ваших,

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

 

[Yoskaldyr]

@grigori ууу как бомбануло...

 

[grigori]

ты о чем? хочешь как в апсторе - сделай список совместимых расширений, делай code review новых версий, и предлагай ставить только их.

наследование от неизвестных классов - это фантазии, а не бизнес

 

[Yoskaldyr]

наследование от неизвестных классов - это фантазии, а не бизнес

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

 

[grigori]

очередное ложное утверждение, которое опровергается фактами, в том числе числами

Читаем: https://ru.wikipedia.org/wiki/Magento
В 2011 ее слили в ebay, в 2015 ebay ее слил дальше, потом ее слили еще раз в 2018, и Adobe, дом престарелых проектов, сократил разработчиков. С первого места в 13м году они ушли на 6е, последние 4 года только минорные релизы.
Магенто уже затонул, что для меня ожидаемо, я общался с их уже закрытым киевским офисом.

 

[AmdY]

очередное ложное утверждение, которое опровергается фактами, в том числе числами

Читаем: https://ru.wikipedia.org/wiki/Magento
В 2011 ее слили в ebay, в 2015 ebay ее слил дальше, потом ее слили еще раз в 2018, и Adobe, дом престарелых проектов, сократил разработчиков. С первого места в 13м году они ушли на 6е, последние 4 года только минорные релизы.
Магенто уже затонул, что для меня ожидаемо, я общался с их уже закрытым киевским офисом.

Всем бы так тонуть

В январе 2017 года Magento получила очередные 250 млн долларов инвестиций для развития на растущих азиатских рынках электронной торговли[9].

 

[grigori]

В общем: в 2011 ebay покупает magento за $180m, в 2015 отдает ее за $200M, в 2017 раунд на $250M. Просрали все полимеры, взяли еще - business as usual.
И всего через год ее покупает Adobe за 1.7 миллиарда несмотря на падение интереса к продукту.

Пишут, что Adobe купила ее чтобы конкурировать с salesforce, и сразу выгнала на мороз сотню дармоедов.
Adobe делает SAAS, развивать open source они не собираются

 

[StalkerClasses]

Ответ на вопрос по прежнему актуален в виде примера.

 

[StalkerClasses]

А можно ли в Laravel например посредника для модели сделать?
laravel model middleware

 

[fixxxer]

А можно ли в Laravel например посредника для модели сделать?
laravel model middleware

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

 

[whirlwind]

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

За трейты/миксины возникает сильное желание бить лицо тому кто это придумал. В низкоуровневых это 100500 этажные шаблоны, фейл компиляции которых превращается в лютый треш для анализа проблемы, либо это обыкновенный процедурный код, скомпанованный в класс путем просовывания руки через Ж. Если у вас взаимодействие классов, то оно априори уникальное и никакими общими примесями это не решается. Ибо класс это по определению нечто уникальное, следовательно на гранях вы получаете либо несовместимые типы, либо сильно разное поведение. В конечном итоге глядя на класс с примесями никогда нельзя определенно сказать, на что конкретно мы смотрим. Что как бы весь смысл "шаблона" извращает.