AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 17.07.2017, 21:25   #141  
ta_and is offline
ta_and
Участник
 
178 / 106 (4) +++++
Регистрация: 26.02.2002
Адрес: СПб
Цитата:
Сообщение от dech Посмотреть сообщение
X++:
    instance.parmRecord(_args.record()); // а так можно?
    instance.parmArgs(_args);            // или вот так?
Вы понимаете разницу между конструктором и методом доступа к внутреннему состоянию (parm*)?
Если да, то тогда зачем эти вопросы?
Если нет, то попробуйте ответить на вопрос - чем отличаются new и construct?
--------
Я утверждаю, что
1. Для подавляющего большинства (99.9%) прикладных классов на вход нужен хотя бы один параметр.
2. Де факто, в ах стандартом для передачи параметров выбран объект класса Аргс.
3. Аргс уже сейчас используется при инициализации всех интерфейсных объектов (формы, отчеты, запускаемые классы с main, даже джобы!)

Почему не продолжить логику и не сделать передачу аргс обязательным параметром при создании любого экземпляра класса?

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

Последний раз редактировалось ta_and; 17.07.2017 в 21:28.
Старый 17.07.2017, 21:55   #142  
pitersky is offline
pitersky
северный Будда
Аватар для pitersky
Ex AND Project
Соотечественники
 
1,259 / 247 (11) ++++++
Регистрация: 26.09.2007
Адрес: Солнечная система
Цитата:
Сообщение от ta_and Посмотреть сообщение
Ссылка на то, что так (без параметров) сделано в кривой реализации пакетов и цил - это то же самое, что сказать, что давайте равняться на жигули как на эталон машиностроения, а не на тойоту например....
Можно сколько угодно критиковать подход к реализации пакетника - но он есть, и под это надо подстраиваться. По крайней мере, пока его не изменит МС. Иначе о каком едином подходе в разработке может идти речь? Если каждый разработчик будет использовать только свои собственные паттерны, то можно сразу говорить о нечитабельности кода в целом
__________________
С уважением,
Вячеслав
Старый 18.07.2017, 05:56   #143  
dech is offline
dech
Участник
Аватар для dech
 
434 / 188 (7) ++++++
Регистрация: 25.06.2009
Адрес: Омск
Цитата:
Сообщение от ta_and Посмотреть сообщение
Я утверждаю, что
1. Для подавляющего большинства (99.9%) прикладных классов на вход нужен хотя бы один параметр.
"Это не есть факт, мсье Дюк." Я не спорю, что любой класс основывается на каких-то исходных данных, но ничего не обязывает передавать их через методы доступа вместо конструктора. В исключительном случае, когда в new() нужно определиться с чем именно работать, да, согласен, это необходимо. Но в том же пакетнике вы не запустите run(), пока не проинициализируете его.
Цитата:
Сообщение от ta_and Посмотреть сообщение
2. Де факто, в ах стандартом для передачи параметров выбран объект класса Аргс.
Да, и обычно это делается методом initFromArgs(). Args предназначен для передачи параметров через MenuItem из форм и меню. Но если класс не вызывается через менюайтем, то это попахивает явным извратом.
Цитата:
Сообщение от ta_and Посмотреть сообщение
3. Аргс уже сейчас используется при инициализации всех интерфейсных объектов (формы, отчеты, запускаемые классы с main, даже джобы!)
Ну естественно. Полностью согласен с этим фактом! Если класс сам по себе имеет возможность запускаться через менюайтем, почему бы даже программно не инициализировать класс через аргс?
Цитата:
Сообщение от ta_and Посмотреть сообщение
Почему не продолжить логику и не сделать передачу аргс обязательным параметром при создании любого экземпляра класса?
Аргс - не панацея. Если классу нужен SalesLines и только он, то зачем городить инициализацию через аргс?
Представьте, что вы пришли в управляющую компанию за справкой. А вам говорят, в течение 5 рабочих дней вы выдадим вам полный комплект документов по вашей квартире. Приходите на следующей неделе." А вы такой: "ну мне же только справку...". А вам отвечают: "Извините, законодательство ввело новый стандарт, на любой запрос мы готовим полный пакет документов."
__________________
// no comments
Старый 18.07.2017, 10:40   #144  
ta_and is offline
ta_and
Участник
 
178 / 106 (4) +++++
Регистрация: 26.02.2002
Адрес: СПб
Цитата:
Сообщение от dech Посмотреть сообщение
Это не есть факт
Приведите пример прикладного класса, которому не нужен ни один параметр?

Цитата:
Сообщение от dech Посмотреть сообщение
Представьте, что вы пришли в управляющую компанию за справкой. А вам говорят, в течение 5 рабочих дней вы выдадим вам полный комплект документов по вашей квартире. Приходите на следующей неделе." А вы такой: "ну мне же только справку...". А вам отвечают: "Извините, законодательство ввело новый стандарт, на любой запрос мы готовим полный пакет документов."
Некорректный пример.
Скорее - это единый формат для всех справок.
Т.е. заголовок, шапка, реквизиты, тело - все отформатировано в едином виде.
если чего-то не нужно, то оно просто пропущено. и место остается пустым.
Зато мы получаем единый формат всех документов. Если нужно получить реквизиты - мы знаем куда смотреть! Если заголовок - что это за документ - смотрим заголовок! в нужном месте. не думая ни о каких других местах и способах достать что же это за документ перед нами и не переворачиваем документ, чтобы посмотреть на обороте, где рыбу заворачивали.
Старый 18.07.2017, 13:35   #145  
dech is offline
dech
Участник
Аватар для dech
 
434 / 188 (7) ++++++
Регистрация: 25.06.2009
Адрес: Омск
Цитата:
Сообщение от ta_and Посмотреть сообщение
Приведите пример прикладного класса, которому не нужен ни один параметр?
Вспомогательные классы проверки условий и утверждений
Цитата:
Сообщение от ta_and Посмотреть сообщение
Некорректный пример.
Да нет, пример самый подходящий. Что я вижу, исходя из нашего разговора? С одной стороны вы хотите обязать new() принимать параметр и считаете это золотым стандартом (которого, кстати не придерживается M$). С другой стороны вы хотите сделать применение Args стандартом де-факто. Т.е. идеальный вариант для вас, это
X++:
void new(Args _args)
Это, конечно, хорошо в какой-то мере и даже где-то в стандарте мелькает, но опять же повторюсь:
Цитата:
Сообщение от dech Посмотреть сообщение
Аргс - не панацея. Если классу нужен SalesLines и только он, то зачем городить инициализацию через аргс?
К примеру, если вы используете класс Map, то не будете же вы аргс заполнять?

Да и что будет, если так делать, как вы хотите? Представляете сколько параметров передается из метода в метод повсюду? Если все это стандартизовать, то боюсь, что от огромного количества экземпляров данного класса AOS-ы начнут дико свапить на диск, а пользователи сожгут вас на костре.
__________________
// no comments
Старый 18.07.2017, 15:25   #146  
ta_and is offline
ta_and
Участник
 
178 / 106 (4) +++++
Регистрация: 26.02.2002
Адрес: СПб
О. Да. 0.1 процента всех классов.

Цитата:
Сообщение от dech Посмотреть сообщение
идеальный вариант, это
X++:
void new(Args _args)
Да. только с маленькой поправкой:
X++:
void new(Args _args = null)
Эта поправка успокоит мятущуюся душу насчет Мар и сервисных классов?

Цитата:
Сообщение от dech Посмотреть сообщение
Представляете сколько параметров передается из метода в метод повсюду?
При чем здесь передача параметров из метода в метод?
Конструктор вызывается один раз для создания экземпляра.
Полюбому в созданный экземпляр передаются входные параметры.
Сейчас как раз это делается с помощью куевой хучи неформализованных методов аля initFromArgs и тому подобной лабудени.
Я предлагаю всего лишь законодательно это закрепить.
Мои мечты все равно не сбудутся. У М$ всегда свои планы на вечер. Но помечтать то я могу?...

Цитата:
Сообщение от dech Посмотреть сообщение
то боюсь, что от огромного количества экземпляров данного класса AOS-ы начнут дико свапить
Огромного количества чего? Того, что уже есть в системе? Что уже и так генерится и существует для каждого интерфейсного элемента и может быть запросто передано в класс? Вы серьезно? Ничего, что все main вызываются с передачей параметра аргс? это Вас не смущает?
Старый 18.07.2017, 19:02   #147  
dech is offline
dech
Участник
Аватар для dech
 
434 / 188 (7) ++++++
Регистрация: 25.06.2009
Адрес: Омск
Я давно понял вашу позицию, но вы упрямо продолжаете держаться за воздух.
Цитата:
Сообщение от ta_and Посмотреть сообщение
О. Да. 0.1 процента всех классов.
Наберите-ка лучше в поиске по содержимому классов такую ключевую фразу:
X++:
void new()
Цитата:
Сообщение от ta_and Посмотреть сообщение
X++:
void new(Args _args = null)
Эта поправка успокоит мятущуюся душу насчет Мар и сервисных классов?
Вот тут я не понял, Вы что, реально и в сервисные классы хотите залезть? Работать с коллекциями через Args? Или как вообще?
Цитата:
Сообщение от ta_and Посмотреть сообщение
При чем здесь передача параметров из метода в метод?
Конструктор вызывается один раз для создания экземпляра.
Полюбому в созданный экземпляр передаются входные параметры.
Сейчас как раз это делается с помощью куевой хучи неформализованных методов аля initFromArgs и тому подобной лабудени.
Т.е. вы видите только те аргсы которые из менюайтемов вылупляются. На основе своих предположений о вашем "правильном" положении вещей в аксапте, я догадываюсь, что в недалеком будущем у вас абсолютно все классы инициализируются через аргс. И каждый, я повторюсь, каждый класс принимает нет тот же самый аргс, который был изначально. Каждому классу нужен будет отдельно созданный инстанс Аргс со своими параметрами.
Цитата:
Сообщение от ta_and Посмотреть сообщение
Огромного количества чего? Того, что уже есть в системе? Что уже и так генерится и существует для каждого интерфейсного элемента и может быть запросто передано в класс? Вы серьезно? Ничего, что все main вызываются с передачей параметра аргс? это Вас не смущает?
Как бы вам объяснить доходчиво... Давайте построим QueryRun таким макаром? Допустим, все работает через аргсы... Что ж, давайте сделаем 3 QueryBuildDataSource, на каждый навешаем по 5 QueryBuildRange... Результат надо передать в Query, а потом уже его получит QueryRun. Т.е. чтобы построить обычный динамический запрос, вы получите 17 разных инстансов Аргс! А если вы инвойс разнести хотите, там в SalesFormLetter не хило так можно развернуться, а? Посчитайте, сколько там в classDeclaration классов, передайте-ка каждому по своему экземпляру Аргс. А потом по цепочке из класса в класс. Они ведь тоже используют какие-то свои классы? Вы хоть раз замеряли производительность, объем используемой памяти? А Если каждый аргс будет держать в себе курсор не с одной записью?

Короче, ваша идея с аргс - чисто солдафонская привычка: грубо, топорно, но зато понятно и надёжно. А какова цена - да не важно совсем, главное работает и всем понятно))).
Всё, я с вами больше не спорю. Нет никакого смысла.
__________________
// no comments
За это сообщение автора поблагодарили: skuull (4).
Старый 18.07.2017, 19:24   #148  
dech is offline
dech
Участник
Аватар для dech
 
434 / 188 (7) ++++++
Регистрация: 25.06.2009
Адрес: Омск
Подытожу немного.
Класс Аргс был создан для того и только для того, чтобы передавать информацию из форм отчетов и меню. Остальное от лукавого.
__________________
// no comments
Старый 19.07.2017, 03:37   #149  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,597 / 510 (21) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от dech Посмотреть сообщение
Короче, ваша идея с аргс - чисто солдафонская привычка: грубо, топорно, но зато понятно и надёжно. А какова цена - да не важно совсем, главное работает и всем понятно))).
Дело не в передаче именно аргс, а в понятном и надежном подходе.
Это может быть и имя, и аргс, и массив параметров.

В стыдном PHP например это делается так
PHP код:
public object ReflectionClass::newInstanceArgs ([ array $args ] ) 
http://php.net/manual/en/reflectionc...stanceargs.php

PHP код:
public object ReflectionClass::newInstance mixed $args [, mixed $... ] ) 
http://php.net/manual/en/reflectionc...ewinstance.php

А есть и такая фишка
ReflectionClass::newInstanceWithoutConstructor — Creates a new class instance without invoking the constructor.
http://php.net/manual/en/reflectionc...onstructor.php

От передачи ссылки или null - системе не поплохеет.

Использование метаданных в случае данной темы - это само по себе не глупо.
Автор темы просто устал от того бардака который привнесли в неплохую и законченную систему.
Солдафонство в том смысле что должен быть единый и единственный фрэймворк в конкретном продукте/платформе, единообразие и следование уставу - это то что доктор студентам прописал
Старый 19.07.2017, 07:08   #150  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
1,970 / 868 (32) +++++++
Регистрация: 03.04.2002
Адрес: Australia
Цитата:
Сообщение от ax_mct Посмотреть сообщение
Дело не в передаче именно аргс, а в понятном и надежном подходе.
Что хорошего в передаче Args, если это не вызов через menuItem? Куча бессмысленных параметров, из которых будет лишь один будет иметь смысл, да и тот предельно обобщенный Object. Т.е. вся надежность в том, что надежно удается обмануть компилятор и словить ошибку в runtime.
Цитата:
Сообщение от ax_mct Посмотреть сообщение
В стыдном PHP например это делается так
Здесь соглашусь. Такого многие стыдятся. Но из уважения к твоим религиозным убеждениям про "граальность" некторых языков, тему развивать не вижу смысла.
__________________
Isn't it nice when things just work?
Старый 19.07.2017, 19:09   #151  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,597 / 510 (21) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от macklakov Посмотреть сообщение
Что хорошего в передаче Args, если это не вызов через menuItem? Куча бессмысленных параметров, из которых будет лишь один будет иметь смысл, да и тот предельно обобщенный Object. Т.е. вся надежность в том, что надежно удается обмануть компилятор и словить ошибку в runtime.

Здесь соглашусь. Такого многие стыдятся. Но из уважения к твоим религиозным убеждениям про "граальность" некторых языков, тему развивать не вижу смысла.
Согласен что Args с тремя лицами (record, enum, object) не шибко прямой и понятный вариант. Но я не сколько об Args как о конкретном варианте, а о тупом солдафонстве которого так не хватает в AX. Чтобы просто и тупо как топор. Тут не так важно что именно, главное что единообразно по всей системе. Множественность фрэймворков под реальные и нереальные проблемы - это бардак там где должна быть казарма.
Собственно старые солдаты и тоскуют о порядке. Которого не стало.

Компилятор как защита от дурака - от дураков не помогает, но помогает делать дураков.
Старый 11.08.2017, 22:16   #152  
mazzy is offline
mazzy
Administrator
Аватар для mazzy
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
Most Valuable Professional
 
28,475 / 3355 (168) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Как подобный класс задач решается у соседей
Алексей Буздин — Чудеса обработки Java-аннотаций при компиляции
__________________
GitHub, Facebook, mazzy.priot, mazzy.music, coub.
Старый 12.08.2017, 02:34   #153  
trud is offline
trud
Участник
 
428 / 300 (11) ++++++
Регистрация: 07.06.2003
Цитата:
Сообщение от mazzy Посмотреть сообщение
Как подобный класс задач решается у соседей
кстати не только у соседей, по подобной схеме работают дата ентити - т.е. компилится не дата ентити, а на ее основе создается класс(со всякими геттерами-сеттерами), туда переносится код из перекрытых методов и работа уже идет с этим классом.
т.е. сама эта конструкция когда я увидел это в первый раз очень удивила, но судя по видео видно какой-то джава разработчик и делал.
очевидный недостаток такой модели - что таблицы имеют сво-во меняться, в них добавляются поля и прочее. а дата ентити этого не знает, что как бы резко усложняет поддержку такой схемы и по сути делает стандартный импорт мало пригодным
За это сообщение автора поблагодарили: mazzy (2).
Старый 12.08.2017, 11:05   #154  
belugin is offline
belugin
Участник
Аватар для belugin
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
Сотрудники Microsoft Dynamics
 
3,935 / 2078 (77) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Цитата:
Сообщение от mazzy Посмотреть сообщение
Как подобный класс задач решается у соседей
TL;DR обработку аннотаций можно из рантайма перенести в компайл тайм с увеличением скорости и понижением рантаймовой гибкости. Приведены примеры из мира JAVA
Теги
sysextension framework, sysoperation framework, как правильно, полезное

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
stephenmann: Technical History of Dynamics AX - From Axapta 3.0 to AX2012 Blog bot DAX Blogs 5 03.03.2017 10:22
dynamicsax-fico: Invoice search AX2012 vs. AX7 (Part 2) Blog bot DAX Blogs 0 01.04.2016 10:11
DAX2009 аналог friend классов. Как сделать? Raven Melancholic DAX: Программирование 9 07.11.2015 23:50
emeadaxsupport: Inventory closing differences between AX4.0 and AX2012 using weighted average costing method Blog bot DAX Blogs 0 27.12.2012 19:11
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 08:11.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.