mfp: Extensible X++: Chain of Command

[Blog bot]

Источник: https://blogs.msdn.microsoft.com/mfp...in-of-command/
==============
As you can see on the Dynamics Roadmap a new capability is being introduced in X++; it enables strongly typed extension capabilities of public and protected methods; including access to public and protected members. Oh; I almost forgot: This is my new favorite X++ feature. See this video to learn more. THIS POST IS PROVIDED...

==============
Источник: https://blogs.msdn.microsoft.com/mfp...in-of-command/

[kashperuk]

Все ознакомтесь

[trud]

Цитата:

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

Все ознакомтесь

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

[skuull]

Цитата:

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

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

В МС уже давно есть тула которая проверяет не сменил ли ты часом сигнатуру метода и разрешает добавлять только опциональные параметры. Появилась она до 7ки. Как уже тут говорили, меняться будут только private и что не успеют завернуть в private до hard seal так тому и быть

[trud]

Цитата:

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

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

так опциональные то параметры тоже все порушат. т.е. их же не будет в коде next экстеншена

[skuull]

Цитата:

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

так опциональные то параметры тоже все порушат. т.е. их же не будет в коде next экстеншена

Откуда инфа ?

[trud]

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

[mazzy]

Цитата:

Сообщение от Blog bot

This is my new favorite X++ feature.

Господи, опять cast.
См. 3:41

[mazzy]

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



вместо атрибута ExtensionOf ключевое слово extends
вместо ключевого слова next - this.
и можно было бы не выполнять никакой работы.

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

вы скажете, что extensions в Аксапте означает совсем не то, что extensions в других языках.
да. в других языках extensions позволяет "добавить метод" в закрытый класс, чтобы остальной код воспринимал добавленный метод как "свой". а в аксапте сделали механизм hook'ов, где механизм extensions вызывает все методы, совпадающие по сигнатуре. Этот механизм в других языках называется hook и относится к технологии создания pugin'ов.


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

чьёрт поберьи
https://www.youtube.com/watch?v=d08EMFNnEXY

[skuull]

Цитата:

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

Господи, опять cast.
См. 3:41

Нам патенты не патентировать...
Я бы лично убил человека который придумал

args.getArgNum()

Так как для обычных методов первый параметр это args.getArgNum(1), а для статических args.getArgNum(0). Т.к. 0 параметром ложиться this, а в статических методах его нет

А все потому что внутри лежит список куда они эти параметры и пихают начиная с this

Вот и приходиться использовать только

args.getArg(identifierStr())

[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

[trud]

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

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

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

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

[EVGL]

Какая вам разница, если это решает насущную проблему? Или лучше было оставить как есть: чтобы 60% кода в системе нельзя было больше расширять?

[mazzy]

Цитата:

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

Какая вам разница, если это решает насущную проблему?

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

Помнится в армии прапорщик говорил: мне не нужно, чтобы вы сделали, мне нужно, чтобы вы за*бались.

Цитата:

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

Или лучше было оставить как есть: чтобы 60% кода в системе нельзя было больше расширять?

Абсолютно ложный выбор.
Запрета расширения не было. Запрет - это нововведение от МС.

В этом смысле да - лучше оставить как есть и не закрывать код.

[mazzy]

Цитата:

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

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

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

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

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

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

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

[EVGL]

Цитата:

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

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

Именно. Никакой разницы если быстрее и меньше кода приходится писать.

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

[fed]

Чтение дискуссии напомнило мой собственный пост 11летней давности.

Цитата:

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

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

[trud]

Цитата:

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

Откуда инфа ?

ну вот кстати, параметр по умолчанию это брекинг ченж

Цитата:

https://blogs.msdn.microsoft.com/mfp...in-of-command/

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