mfp: Extensible X++: Chain of Command

[kashperuk]

Цитата:

Сообщение от mazzy

Господи, они переизобрели наследование, которое уже было в Аксапте с 1998 года.
Аллилуя!

На самом деле, есть несколько существенных отличий.

Наследование не позволит вам сделать то, что делает CoC, на статических методах.

Наследование не позволит нормально сосуществовать двум различным имплементациям которые одновременно должны влиять на выполнение кода.

[mazzy]

Цитата:

Сообщение от kashperuk

Наследование не позволит вам сделать то, что делает CoC, на статических методах.

Наследование не позволит нормально сосуществовать двум различным имплементациям которые одновременно должны влиять на выполнение кода.

А как расшифровывается CoC?

Дык.
Механизм extensions в Аксапте - это механизм плугинов у нормальных людей.
механизм плугинов позволяет вызвать все методы с одинаковыми сигнатурами, которые находятся в разных местах.

В этом смысле наследование и плугины - да, ортогональны друг-другу.

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

=========================
Я о чем:

1. то, что они сделали как наследование - аллилуя! только чего же сразу так не сделали?
2. то, что они задействовали новое ключевое слово next - отвратительно. Это отдаляет X++ от других языков.
3. то, что они не использовали ключевое слово для перегрузки (типа overload, virtual или подобное) - по современным меркам хорошо. Но см. аргументацию Страустрапа в пользу явного указания этих ключевых слов
4. то, что они по сути сделали friend-класс (дали доступ к внутренним переменным) - очень спорно. для extension-методов не определен порядок вызова, а внутренние переменные устанавливают статус. Поэтому ооочень будет не хватает управлением порядка вызовов extension-методов

в общем, extension-методы не новость, есть куча аналогов.
и очень хочется видеть не заклинания (cast) в стиле "This is my new favorite X++ feature", а сравнение с другими инструментами/языками. и анализ плюсов-минусов и способов минимизации минусов.

Для сравнения см. того же Страустрапа. Да, не во всем он по итогу прав (см. тот же Boost). но его доводы внушают уважение и к ним стоит прислушаться.

а тут броуновское движение какое-то.
Почему в одном случае таки расширили значение ключевого слова next, а в другом вставили какой-то атрибут? какое-нибудь ключевое слово использовать в том же месте, где "живут" extends-implements. Например, by, case, like. Да хоть тот же delegate!
https://msdn.microsoft.com/en-us/lib...or=-2147217396

[mazzy]

Цитата:

Сообщение от mazzy

то, что они задействовали новое ключевое слово next - отвратительно. Это отдаляет X++ от других языков.

Опять же, в Аксапте УЖЕ есть аналоги - вызов методов из MAPS (объект AOT, который является интерфейсом для нескольких таблиц)
Синтаксис ужасный, конечно. Но он уже есть.

Зачем ключевое слово там где без него можно обойтись?
и атрибут там, где как раз требуется ключевое слово.

сейчас, без ключевого слова, смысл private/protected/public в extension-классе предельно извратный.

[belugin]

Цитата:

Сообщение от mazzy

Зачем ключевое слово там где без него можно обойтись?
и атрибут там, где как раз требуется ключевое слово.

Как обойтись? Я вижу только один способ. Сделать какой-нибудь предопределенное поле для обозначения оборачиваемого объекта (next.method() вместо next method()).

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

[mazzy]

Цитата:

Сообщение от mazzy

то, что они задействовали новое ключевое слово next - отвратительно. Это отдаляет X++ от других языков.

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

например, мы создаем расширение post, которое должно срабатывать во всех журналах (в ГК, в складских журналах, в авансовых отчетах, в проектах и в других).

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

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

=======================
Господи, ну почему сразу всплывает столько вопросов к "favorite X++ feature", стоит хотя бы на 10-15 минут подумать об этой фиче.

[kashperuk]

Цитата:

Сообщение от mazzy

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

например, мы создаем расширение post, которое должно срабатывать во всех журналах (в ГК, в складских журналах, в авансовых отчетах, в проектах и в других).

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

Я не понял этот пример. Напиши что именно имелось ввиду?
Можно заврэпить конкретный метод конкретного саб-класса, если нужно сделать только что-то именно для этого саб-класса.

[mazzy]

Цитата:

Сообщение от kashperuk

Я не понял этот пример. Напиши что именно имелось ввиду?

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

Цитата:

Сообщение от kashperuk

Можно заврэпить конкретный метод конкретного саб-класса

да-да. я об этом.
ты очень точно написал в единственном числе.

хотя атрибуты, представленные в исходном видео, вполне допускают несколько extensionOf-классов.