Denis Trunin's Blogs: 30 additional methods to the Global class

[mazzy]

и еще. а зачем нужен метод cObj?

понятно, что он делает downcast. но зачем?
насколько я понимаю, для System.Object он все равно не подходит.

[trud]

Цитата:

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

можно добавить:
NZ
StrAfter
StrAfterChar
strAfterLast
strAfterLastChar
StrBefore
StrBeforeChar
StrBeforeLast
StrBeforeLastChar
StrLeft
StrPadLeft
StrPadRight
StrRight
StrSplit

А что такое NZ? по остальному - в D365 лучше наверное использовать класс System.String - там есть просто все и даже больше. Если пришлете тексты, могу включить, но лучше наверное в отдельный класс DEVStringHelper

Цитата:

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

и еще. а зачем нужен метод cObj?
понятно, что он делает downcast. но зачем?
насколько я понимаю, для System.Object он все равно не подходит.

Если не ошибаюсь изначально позаимствовал у Ромы, нужен если у вас есть FormRun и на нем надо вызвать метод. В последнее время кстати приходилось несколько раз пользовать(хотя понятно что лучше этого избегать). Врядли он будет работать для System.Object

Цитата:

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

и еще. уж извините

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

Цитата:

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

часто видел метод countTotalQuick на проектах где участвовал Колумбус.
то, что метод в Global, а не в SysQuery - фиг с ним.
то, что возвращает Integer, а не Int64 - тоже фиг с ним.

Но почему пакуется queryRun, а не Query?

Вроде метод выполняется там, где вызывается (нет модификатора server/client), поэтому нет передачи объекта между сервером и клиентом.

ведь можно было бы и так:

static Integer countTotalQuick(QueryRun _queryRun)
    {
        container               queryPack = _queryRun.Query().pack();
        Query                   countQuery = new Query(queryPack);
...

но сделано вот так:

static Integer countTotalQuick(QueryRun _queryRun)
    {
        container               queryPack = _queryRun.pack();
        Query                   countQuery;
        QueryRun                countQueryRun;
        ;
        countQueryRun   = new QueryRun(queryPack);
        countQuery      = countQueryRun.query();
...

это не в качестве критики, а просто интересно. может я чего не знаю?

Идея метода - продублировать стандартный SysQuery::countPrim, но без условия

if (countQuery.dataSourceCount() == 1)
{ qbds.addSelectionField(fieldNum(Common, RecId), SelectionField::Count);     }

т.е. Count использовать всегда. зачем там пакуется QueryRun и почему они возвращают Integer я честно говоря не знаю, но идея была чтобы заменить один на другой. А какие с этим проблемы?

[mazzy]

Цитата:

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

А что такое NZ?

NotZero - принимает два аргумента. возвращает первый, если он не пустой и второй, если первый пустой.
удобнее, чем тренарный оператор, если второй параметр что-то быстро вычисляемое (константа, strfmt и т.п.)

Цитата:

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

по остальному - в D365 лучше наверное использовать класс System.String - там есть просто все и даже больше.

не очень больше.
System.String не так работает на вправо-выровнянных строках.
а в предыдущих версиях требует постоянного InteropPermission (будь проклят тот архитектор, кто ввел эту шнягу)

Цитата:

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

Если пришлете тексты, могу включить, но лучше наверное в отдельный класс DEVStringHelper

Да, опубликую, пришлю.

только наоборот
это методы работы с рэнджами, буферами, датасорсами и прочими сложными объектами нужно переносить в отдельные классы - SysQuery, SysDataSource, SysRecord, SysArgs.
а методы конвертации базовых типов как раз просятся в Global

Цитата:

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

Если не ошибаюсь изначально позаимствовал у Ромы, нужен если у вас есть FormRun и на нем надо вызвать метод. В последнее время кстати приходилось несколько раз пользовать(хотя понятно что лучше этого избегать). Врядли он будет работать для System.Object

эх, Рома, Рома.
Понятно. Он использует это для получения внутреннего представления, насколько я помню. Дикие хаки. Но эффективные, чёрт побери.
Насколько я понимаю, в 365fo контейнер реализован на System.Array, поэтому дикие хаки с cObject работать не должны. Но в этом расширении метод cObject предлагается. Вот я и удивляюсь - может еще как это можно использовать?

Цитата:

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

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

Ок, спасибо.
Я тоже за критику. Просто с этим случаем у меня подозрение, что это я чего-то не знаю.

Цитата:

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

Идея метода - продублировать стандартный SysQuery::countPrim, но без условия

это-то понятно. без вопросов.
вопрос - почему pack применяется для QueryRun, а не для Query.

Цитата:

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

зачем там пакуется QueryRun и почему они возвращают Integer я честно говоря не знаю, но идея была чтобы заменить один на другой. А какие с этим проблемы?

не знаю. вот не знание то и беспокоит. вдруг, проблемы таки есть?

[trud]

Цитата:

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

это методы работы с рэнджами, буферами, датасорсами и прочими сложными объектами нужно переносить в отдельные классы - SysQuery, SysDataSource, SysRecord, SysArgs.

Такая схема не будет работать при аутсорсинговом программировании(т.е. изначально эти все методы и были разбиты по данным классам). При попытке использовать данные расширения велика вероятность что вам вернут задачу в доработку с комментарием - "убрать код не относящийся к задаче."
Доходило до смешного - мы помогали нашим UK коллегам, и начали с импорта всяких утилит, причем в каком-то минимальном варианте, через пару дней пришло разгневанное письмо от вед.разработчика проекта, которое она отправила к ПМ с пометкой важно - типа эти русские заимпортили какие-то классы, я не знаю что мне делать, я же предупреждала что не надо их брать...
Ну т.е. надо иметь максимально удобный к установке вариант, допускающий легкую частичную установку(т.е. методы должны минимально вызывать друг друга), плюс не заменять стандарт

Цитата:

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

эх, Рома, Рома.
Понятно. Он использует это для получения внутреннего представления, насколько я помню. Дикие хаки. Но эффективные, чёрт побери.

Да, если бы Рома устроился архитетектором в МС, то сейчас бы не было тем "Интеграция - использовать стандарт или писать на коленке ? "

[SRF]

В двенашке и этого нет. Видимо потому, что

Цитата:

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

не заменять стандарт

[Logger]

Цитата:

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

Но в этом расширении метод cObject предлагается. Вот я и удивляюсь - может еще как это можно использовать?

Недавно писал такой же метод cObject .

Мне он пригодился для таких конструкций:
Раньше можно было написать

if (... && SysDictClass::is(element.args().caller().runBase(), ClassNum(MyClass))

теперь аналог

if (... && element.args().caller().runBase() is MyClass)

не прокатывает потому что element.args().caller().runBase() это с точки зрения компилятора - anyType и он автоматом не приводится к Object

теперь приходится писать

if (... && cObject(element.args().caller().runBase()) is MyClass)