04.07.2017, 23:13 | #1 |
Участник
|
mfp: Extensible X++: Chain of Command
Источник: 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/
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору. |
|
05.07.2017, 02:14 | #3 |
Участник
|
фича несомненно хорошая, но непонятно как это будет работать.
т.е. в Микрософт будет введен запрет на добавление в протектед методы параметров и изменения любых переменных класса? а если добавить нужно? та же локализация добавляет кучу всего если жесткого запрета не будет, то непонятно чем был плох оверлеинг |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
05.07.2017, 07:30 | #4 |
Участник
|
Цитата:
Сообщение от trud
фича несомненно хорошая, но непонятно как это будет работать.
т.е. в Микрософт будет введен запрет на добавление в протектед методы параметров и изменения любых переменных класса? а если добавить нужно? та же локализация добавляет кучу всего если жесткого запрета не будет, то непонятно чем был плох оверлеинг |
|
05.07.2017, 07:59 | #5 |
Участник
|
|
|
05.07.2017, 09:10 | #6 |
Участник
|
|
|
05.07.2017, 10:37 | #7 |
Участник
|
просто предполагаю. надо дождаться релиза конечно
если нет, получается сигнатура экстеншн метода может не совпадать с сигнатурой основного класса, надо будет перечислять только обязательные параметры, интересный момент конечно |
|
05.07.2017, 10:47 | #8 |
Участник
|
|
|
05.07.2017, 11:11 | #9 |
Участник
|
Господи, они переизобрели наследование, которое уже было в Аксапте с 1998 года.
Аллилуя! вместо атрибута ExtensionOf ключевое слово extends вместо ключевого слова next - this. и можно было бы не выполнять никакой работы. вы скажете, что одно семейство классов нельзя разбить на разные модели. да. но модели - изобретение МС. могли бы и расширить правила работы с моделями. вы скажете, что extensions в Аксапте означает совсем не то, что extensions в других языках. да. в других языках extensions позволяет "добавить метод" в закрытый класс, чтобы остальной код воспринимал добавленный метод как "свой". а в аксапте сделали механизм hook'ов, где механизм extensions вызывает все методы, совпадающие по сигнатуре. Этот механизм в других языках называется hook и относится к технологии создания pugin'ов. в общем, получили x++, который сильно отличается от других мейнстримовых языков. чьёрт поберьи https://www.youtube.com/watch?v=d08EMFNnEXY |
|
05.07.2017, 11:13 | #10 |
Участник
|
Нам патенты не патентировать...
Я бы лично убил человека который придумал X++: args.getArgNum() А все потому что внутри лежит список куда они эти параметры и пихают начиная с this Вот и приходиться использовать только X++: args.getArg(identifierStr()) Последний раз редактировалось skuull; 05.07.2017 в 11:16. |
|
05.07.2017, 11:25 | #11 |
Участник
|
Цитата:
Наследование не позволит вам сделать то, что делает CoC, на статических методах. Наследование не позволит нормально сосуществовать двум различным имплементациям которые одновременно должны влиять на выполнение кода. |
|
05.07.2017, 11:44 | #12 |
Участник
|
Цитата:
Дык. Механизм extensions в Аксапте - это механизм плугинов у нормальных людей. механизм плугинов позволяет вызвать все методы с одинаковыми сигнатурами, которые находятся в разных местах. В этом смысле наследование и плугины - да, ортогональны друг-другу. Но опять же - майкрософт ведут себя как пионеры-первопроходцы, как будто не было нескольких десятилетий после изобретения плугинов, отважно наступая на все грабли. ========================= Я о чем:
в общем, 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 |
|
05.07.2017, 11:48 | #13 |
Участник
|
я на самом деле жду когда кому-то придет в голову что эти методы должны вызываться не случайным образом(как делают сейча), а в обределенном порядке (типа сначала для экстеншена клиента, потом для экстеншена ISV, потом уже sys). слои для такого очевидно не подходят, ибо это "изобретено не нами"
|
|
|
За это сообщение автора поблагодарили: S.Kuskov (2), mazzy (2). |
05.07.2017, 11:54 | #14 |
Участник
|
Цитата:
Синтаксис ужасный, конечно. Но он уже есть. Зачем ключевое слово там где без него можно обойтись? и атрибут там, где как раз требуется ключевое слово. сейчас, без ключевого слова, смысл private/protected/public в extension-классе предельно извратный. |
|
05.07.2017, 11:58 | #15 |
Banned
|
Какая вам разница, если это решает насущную проблему? Или лучше было оставить как есть: чтобы 60% кода в системе нельзя было больше расширять?
|
|
05.07.2017, 12:04 | #16 |
Участник
|
оО. И в самом деле, какая разница как копать траншею - саперной лопаткой или экскаватором. Какая разница чем чистить унитаз - можно и зубной щеткой.
Помнится в армии прапорщик говорил: мне не нужно, чтобы вы сделали, мне нужно, чтобы вы за*бались. Цитата:
Запрета расширения не было. Запрет - это нововведение от МС. В этом смысле да - лучше оставить как есть и не закрывать код. |
|
05.07.2017, 12:14 | #17 |
Участник
|
Цитата:
ключевое слово next накладывает сильные ограничения в случае, если один метод в одном классе расширяет несколько других базовых. например, мы создаем расширение post, которое должно срабатывать во всех журналах (в ГК, в складских журналах, в авансовых отчетах, в проектах и в других). имея только ключевое слово next нельзя будет указать какой именно метод расширяемого класса вызываем. опять же, навсидку думается, что синтаксис вызова метода в map решил бы и эту проблему. и, похоже, господа архитекторы не предполагали, что кто-то захочет сделать расширение для нескольких классов. Хотя атрибуты это позволяют сделать. ======================= Господи, ну почему сразу всплывает столько вопросов к "favorite X++ feature", стоит хотя бы на 10-15 минут подумать об этой фиче. Последний раз редактировалось mazzy; 05.07.2017 в 12:16. |
|
05.07.2017, 12:31 | #18 |
Banned
|
Цитата:
Кстати, как специалист по домашнему хозяйству с пятилетним опытом холостяка должен отметить, что как минимум душевую кабину удобно чистить зубной щеткой в малодоступных местах. |
|
05.07.2017, 12:33 | #19 |
Moderator
|
Чтение дискуссии напомнило мой собственный пост 11летней давности.
Цитата:
Вообще - по моему нынешнее положение с развитием Аксапта заставляет вспомнить старый советский анекдот, про то как какой-то пожарный инспектор, после успешной проверки какого-то НИИ, ради интереса спросил директора института
- А чем вы все здесь вообще занимаетесь ? - Науку в бок двигаем - Как-так ? - Вперед - ума не хватает, назад начальство не позволяет, вот мы ее в бок и двигаем. Последний раз редактировалось fed; 05.07.2017 в 13:26. |
|
|
За это сообщение автора поблагодарили: trud (1), ax_mct (10), AlexSD (3), pedrozzz (1). |
05.07.2017, 14:39 | #20 |
Участник
|
ну вот кстати, параметр по умолчанию это брекинг ченж
вообще конечно непонятно, в 2012 мы перетаскиваем свой солюшн на каждый CU и практически в каждом CU добавляются какие-нибудь тайские или бразильские параметры в "популярных" методах. Теперь типа не будут, но за счет чего реально движение вбок |
|
|
За это сообщение автора поблагодарили: ax_mct (10). |