Показать сообщение отдельно
Старый 18.10.2016, 17:46   #1  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5813 (201) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от 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

Последний раз редактировалось gl00mie; 18.10.2016 в 19:43. Причина: стилистика
За это сообщение автора поблагодарили: mazzy (5).