AX2012. Цель атрибутов в расширении наследования классов

[ta_and]

Цитата:

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

Почему не AnyType

Потому что анитайп слишком расплывчато. Он не типизирован и не прозрачен. Неизвестно чего он него ждать.
Аргс используется как буфер обмена повсеместно, во всей системе, формы, main, джобы...Это де-факто - параметр по умолчанию. Почему бы его не использовать и для инициализации классов?

[belugin]

Цитата:

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

Потому что анитайп слишком расплывчато. Он не типизирован и не прозрачен. Неизвестно чего он него ждать.

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

Аргс используется не повсеместно а только в коде который вызывается непосредственно из UI. Он содержит UI специфичные параметры, а остальное фактически так же нетипизировано как AnyType

[mazzy]

Цитата:

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

Аргс используется не повсеместно а только в коде который вызывается непосредственно из UI.

да. права, метка и подсказка на разных языках, параметр где запускать... и прочие "специфичные" UI параметры.
и не говори, очень жаль, что "используется не повсеместно".

[ta_and]

Цитата:

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

только там может быть незаполнено

То, что не заполнено, как раз не проблема.
Это дело уже инициализируемого объекта - проверить входные данные.
Главное что для них есть место.
Всем известное место.
Повсеместно используемое место.
и если бы это место еще использовалось бы при инициализации любого экземпляра, то это было бы замечательно. Ну хотя бы с дефолтным нуллом.
Наподобие мэйн.
На крайняк всегда можно перекрыть метод new и добавить - изменить входные параметры...

[belugin]

Цитата:

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

Повсеместно используемое место.

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

Почитайте про design by contract и вообще про принципы проектирования

[ta_and]

Цитата:

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

Это все равно, что AnyType

Нет. не все равно.
На моем опыте 90% классов на вход принимают енум и курсор.
Эти 90% классов вполне покрываются передачей на вход аргс.
Можно считать, что это типизированная передача фиксированных параметров в контракте. Возможно, для некоторых классов избыточная. Но зато (если бы это было так) унифицированная для всех объектов системы! А это приводит в порядок мысли в голове разработчиков новой функциональности, и конкретным ожиданиям для существующей. И на 90%!!! исключает зоопарк в передаваемых структурах данных при инициализации.
Энитайп же ни о чем не говорит. Совершенно. Он не типизирован. Поэтому использование его в контракте не является правильным решением.
Проверка переданных данных лежит полюбому на создаваемом классе.
---------
Вы же не будете утверждать, что использование контракта избавляет от необходимости проверки входных данных?

[belugin]

Цитата:

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

Нет. не все равно.
На моем опыте 90% классов на вход принимают енум и курсор.
Эти 90% классов вполне покрываются передачей на вход аргс.
Энитайп же ни о чем не говорит. Совершенно. Он не типизирован.

Так args содержит any type. И 90% классов (кстати интересно вообще всех классов или классов, которые вы добавляете/изменяете) принимают не запись вообще а запись какого-то определенного типа. И энам тоже не любой. И указывание не нужных параметров создает кашу в голове а не приводит мозги в порядок.

Цитата:

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

Почитайте про design by contact - это не то же самое что data contracts .

Да проверять нужно по-любому. По крайней мере пока нет зависимых типов. Но я бы сделал наоборот - не передавал бы везде запись и enum - нужны они там или не нужны а в menu item поздравлял бы указывать только те параметры которые принимает main: нужна запись - попросить запись причем нужного типа, нужен enum - попросить enum, нужно два - просить два.

Вы же сами не хотите any type - потому что нужна проверка при компиляции. Но почему-то хотите any record и anyenum.

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

[ta_and]

Цитата:

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

только те параметры которые принимает main

Эти слова да МС бы в уши... Но это другой уровень организации вызова объектов. Слишком кардинально нужно менять всю систему. Это уже не один параметр, это меняет не только один системный вызов обжекта, но требует изменения всей среды разработки и передачи событий между объектами... В общем, это на порядок более нереальная придумка, чем моя с аргс. )) Хотя, я полностью ЗА!

[ax_mct]

Цитата:

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

Почитайте про design by contract и вообще про принципы проектирования

Вот лучше бы те кто такое читают в Аксапту бы не лезли. Ей от этого дурно, а сейчас вообще подыхает

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

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

Я например не вижу как это что-то упрощает или экономит в контексте даже AX7. Не нужно загодя решать потенциальные проблемы. Это overengineering.

[belugin]

Цитата:

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

Вот лучше бы те кто такое читают в Аксапту бы не лезли. Ей от этого дурно, а сейчас вообще подыхает

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

.

Откуда вы решили что это из книжек по проектированию . Про overengineering там тоже есть.

[ax_mct]

Цитата:

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

Откуда вы решили что это из книжек по проектированию . Про overengineering там тоже есть.

Наши знания и компетентность - отдельно, Аксапта и уместность для нее паттернов - отдельно.

Мой пойнт в том что любые паттерны проектирования - overengineering. В том числе данный патентованный способ использования атрибутов. Оverengineering до тех пор пока не доказано и показано обратное. Как с той вилкой для подьема по стене.

Аксапта уже имела достаточно своих паттернов и сложившийся Best Practices, любое привнесение новых паттернов (на фоне наплевательства в системном коде на платформу как таковую), - кроме удорожания программирования ничего не с собой не несет.

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