Разминка. Принять в метод map или таблицу

[Владимир Максимов]

Цитата:

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

2.
isMap хорош, когда метод четко знает какой именно мап в него приходит
а если допустимо передавать разные мапы? как узнать какой именно пришел в common? делать switch на tablenum?

Этот момент не понял.

Если нам надо знать, что именно мы получили, и от этого строить обработку, то именно что switch на tablenum. Нам же все-равно надо будет как-то организовать ветвление кода в зависимости от полученного параметра. Или о чем тогда речь?

[mazzy]

Цитата:

Сообщение от Владимир Максимов

Этот момент не понял.

Если нам надо знать, что именно мы получили, и от этого строить обработку, то именно что switch на tablenum. Нам же все-равно надо будет как-то организовать ветвление кода в зависимости от полученного параметра. Или о чем тогда речь?

))))
"для определенности, пусть будет https://github.com/mazzy-ax/SysCustVend"

предположим я хочу, чтобы метод возвратил признак "Клиент", если на вход поданы таблицы/мапы, связанные с клиентами, и возвратил "Поставщик", если на вход поданы таблицы/мапы связанные с поставщиками. пример вызова в разными объектами я написал выше.

как отличить один неинициализированный мап от другого в методе?

как отличить один инициализированный мап от другого, если они ссылаются на одни и те же таблицы. например, первый мап - на custTrans, vendTrans, а второй мап - на custTrans, vendTrans, emplTrans.

===================
повторюсь, что это всего лишь разминка для ума. и часть совсем другой задачи, из которой я и вытащил собственно вопрос. скорее всего, задачу я полностью переформулирую. но на вопрос хотелось бы знать ответ, если он есть конечно.

[gl00mie]

Цитата:

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

"для определенности, пусть будет https://github.com/mazzy-ax/SysCustVend"
предположим я хочу, чтобы метод возвратил признак "Клиент", если на вход поданы таблицы/мапы, связанные с клиентами, и возвратил "Поставщик", если на вход поданы таблицы/мапы связанные с поставщиками.

В моем понимании Map'ы в X++ - это своего рода реализация ООП для таблиц, причем не аналог наследования в AX 2012, а скорее аналог интерфейсов и разделяемых классов (partial classes) вместе взятых. Из этого следует, что код, работающий с Map'ами, в design time всегда работает с неким интерфейсом (в терминах ООП), а в run time всегда работает с некой конкретной реализацией этого интерфейса - таблицей.
Map проявляет свою сущность интерфейса через предоставление стороннему коду названий и базовых типов полей, а также сигнатур экземплярных табличных методов.
Map проявляет свою сущность разделяемого класса через реализацию логики экземплярных табличных методов.

Из вышесказанного следует несколько выводов:

• если коду, работающему с Map, нужно как-то различать те реализации (таблицы), которые могут прийти под видом Map в run time, то либо в Map должно быть какое-то поле, которое в таблицах будет заполнено соотв. образом, либо в Map должен быть какой-то метод, возвращающий соотв. признак, а в таблицах - его реализация. Надо помнить, что вызов mapBuffer.method() в run time приводит к попытке вызова соотв. метода таблицы, и если она не реализует метод с такой сигнатурой, то вызов завершится ошибкой времени выполнения.
• передача коду в run time неинициализированного Map'а - это своего рода форс-мажор, схожий с передачей null вместо объекта класса, реализующего определенный интерфейс.
• если код предназначен для работы с разными Map'ами, то, видимо, он использует этот тип объектов приложения не как "ООП для таблиц", а совсем иначе, и тогда получается, что такому коду вообще должно быть без разницы, пришел ли ему на вход буфер таблицы, Map, View... Стало быть, такой код по идее должен работать с Common и механизмами отражения.

Цитата:

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

как отличить один неинициализированный мап от другого в методе?

По значению поля TableId.

Цитата:

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

как отличить один инициализированный мап от другого, если они ссылаются на одни и те же таблицы. например, первый мап - на custTrans, vendTrans, а второй мап - на custTrans, vendTrans, emplTrans.

Никак: исходя из идеологии Map, в run time всегда должна приходить реализация, т.е. буфер конкретной таблицы. Если вам на вход пришел буфер таблицы CustTrans, то не имеет значения, под видом какого Map этот буфер в design time указан в вызывающем коде и Map ли там вообще - может, Common, а может, anytype

Резюме: в представленной постановке задачи код должен работать не с anytype и не с Map, а с Common и использовать API отражения для получения нужной информации. Анализ Common.TableId в коде ничем не хуже анализа Map.TableId