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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 17.07.2017, 21:25   #141  
ta_and is offline
ta_and
Участник
 
183 / 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,262 / 247 (11) ++++++
Регистрация: 26.09.2007
Адрес: Солнечная система
Цитата:
Сообщение от ta_and Посмотреть сообщение
Ссылка на то, что так (без параметров) сделано в кривой реализации пакетов и цил - это то же самое, что сказать, что давайте равняться на жигули как на эталон машиностроения, а не на тойоту например....
Можно сколько угодно критиковать подход к реализации пакетника - но он есть, и под это надо подстраиваться. По крайней мере, пока его не изменит МС. Иначе о каком едином подходе в разработке может идти речь? Если каждый разработчик будет использовать только свои собственные паттерны, то можно сразу говорить о нечитабельности кода в целом
__________________
С уважением,
Вячеслав
Старый 18.07.2017, 05:56   #143  
dech is offline
dech
Участник
Аватар для dech
 
438 / 189 (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
Участник
 
183 / 106 (4) +++++
Регистрация: 26.02.2002
Адрес: СПб
Цитата:
Сообщение от dech Посмотреть сообщение
Это не есть факт
Приведите пример прикладного класса, которому не нужен ни один параметр?

Цитата:
Сообщение от dech Посмотреть сообщение
Представьте, что вы пришли в управляющую компанию за справкой. А вам говорят, в течение 5 рабочих дней вы выдадим вам полный комплект документов по вашей квартире. Приходите на следующей неделе." А вы такой: "ну мне же только справку...". А вам отвечают: "Извините, законодательство ввело новый стандарт, на любой запрос мы готовим полный пакет документов."
Некорректный пример.
Скорее - это единый формат для всех справок.
Т.е. заголовок, шапка, реквизиты, тело - все отформатировано в едином виде.
если чего-то не нужно, то оно просто пропущено. и место остается пустым.
Зато мы получаем единый формат всех документов. Если нужно получить реквизиты - мы знаем куда смотреть! Если заголовок - что это за документ - смотрим заголовок! в нужном месте. не думая ни о каких других местах и способах достать что же это за документ перед нами и не переворачиваем документ, чтобы посмотреть на обороте, где рыбу заворачивали.
Старый 18.07.2017, 13:35   #145  
dech is offline
dech
Участник
Аватар для dech
 
438 / 189 (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
Участник
 
183 / 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
 
438 / 189 (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
 
438 / 189 (7) ++++++
Регистрация: 25.06.2009
Адрес: Омск
Подытожу немного.
Класс Аргс был создан для того и только для того, чтобы передавать информацию из форм отчетов и меню. Остальное от лукавого.
__________________
// no comments
Старый 19.07.2017, 03:37   #149  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,683 / 531 (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 / 873 (33) +++++++
Регистрация: 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,683 / 531 (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
Most Valuable Professional
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
28,592 / 3395 (171) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Как подобный класс задач решается у соседей
Алексей Буздин — Чудеса обработки Java-аннотаций при компиляции
__________________
GitHub, Facebook, mazzy.priot, mazzy.music, coub.
Старый 12.08.2017, 02:34   #153  
online
trud
Участник
 
454 / 324 (11) ++++++
Регистрация: 07.06.2003
Цитата:
Сообщение от mazzy Посмотреть сообщение
Как подобный класс задач решается у соседей
кстати не только у соседей, по подобной схеме работают дата ентити - т.е. компилится не дата ентити, а на ее основе создается класс(со всякими геттерами-сеттерами), туда переносится код из перекрытых методов и работа уже идет с этим классом.
т.е. сама эта конструкция когда я увидел это в первый раз очень удивила, но судя по видео видно какой-то джава разработчик и делал.
очевидный недостаток такой модели - что таблицы имеют сво-во меняться, в них добавляются поля и прочее. а дата ентити этого не знает, что как бы резко усложняет поддержку такой схемы и по сути делает стандартный импорт мало пригодным
За это сообщение автора поблагодарили: mazzy (2).
Старый 12.08.2017, 11:05   #154  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
3,989 / 2133 (79) +++++++++
Регистрация: 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, время: 15:55.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.