Доброго всем дня
Пишу некий универсальный класс, который должен обрабатывать несколько таблиц. В каждый момент времени он обрабатывает только одну таблицу. Требуется в классе создать атрибут, который содержит данные из текущей таблицы (как производится их отбор - здесь неважно). Вопрос: как создать ОДИН атрибут, ко орый может ссылаться на НЕСКОЛЬКО таблиц? Конструкции типа TYPE STANDART TABLE, TYPE ANY TABLE, TYPE TABLE не проходят, т.к. это generic data types, которые в атрибутах использовать нельзя.
Аналогичный вопрос - как создать параметр методов данного класса, параметрами которых являются записи текущей таблицы. Соответственно тип параметра должен быть Структура текущей таблицы.

Может, как-то так?

Спасибо за идею.
Правда, встал другой вопрос: как описать переменную типа any table?
Код:
DATA: any_table TYPE any table,
any_table_data LIKE LINE OF any_table
также ругается на generic data type

Через field-symbol.
Потом из CL_ABAP_TYPEDESCR получаем описание таблицы и делаем желаемое.

Выше приведён код, который как раз это и делает.

Не очень понимаю, где вы пытаетесь это делать. В каком-то методе своего класса? Так не получится.

Если вы посмотрите на мои фрагменты кода, то увидите, что в конструкторе внешняя таблица (точнее, ссылка на нее) принимается в класс через параметр itab, который как раз ANY TABLE. Т.е. предполагается, что таблица передается в класс извне в момент создания объекта вашего класса оператором:

В том же конструкторе переданная таблица сразу обуздывается путем создания указателей: на всю таблицу (tab_pointer) и на одну запись (рабочую область, wa_pointer). Всё! При помощи двух этих параметров вы получаете возможность трогать таблицу в любом методе данного класса. Сама таблица при этом физически в класс не передается и находится "где-то в вызывающей программе".

Далее в конкретном методе вы делаете деРеференс (->*) указателей, превращая их в филд-симболы (<tab_data>,<wa_data>), с которыми уже можно оперировать внутри метода как с обычными таблицами и строками. Дереференс придется делать в каждом методе, который прикасается к таблице. Потому что филд-симболы не могут быть объявлены как аттрибуты класса, но могут быть объявлены в конкретном методе. Запасайтесь терпением, таковы правила игры.

Если я в чем-то неправ (мой ABAP-опыт пока невелик), пусть старшие товарищи меня поправят

Да. Чтобы в классе всегда иметь под рукой информацию о структуре текущей таблицы надо:

1. определить аттрибут класса в секции DEFINITION:

2. в коде конструктора после определения указателя рабочей области получить ссылку на структуру:

3. далее в конкретном методе использовать, например, цикл для доступа к данным по структуре таблицы; это тоже таблица, в которой каждая строчка представляет собой поле исследуемой таблицы:

ABAP - довольно-таки "жесткий" язык и в нём трудно создать сколько-нибудь эффектные динамические конструкции, типа Ваших пожеланий.
В общем, до python'а далековато будет..))
Попробуйте посмотреть на возможности динамической компиляции - это когда "на ходу" составляется и компилится произвольный ABAP-код - в этом коде можно воплотить любые фантазии. Правда, есть некие ограничения.. но, возможно, они для Вас не будут существенными.

Рабочее решение уже предложено Gustav. Почему Вы считаете его неэффективным?

А зачем в данном случае?

оффтоп: А что, на python есть крупные ERP-системы?

Эффекта нет. ^___~

Иногда хочется шаблоны и перегрузку. И увидеть объектно-ориентированный API равный хоть BAPI.

Приведите свой код.

Это шутка была. «Эффектно».

недавно перешли на abap?

А где я об этом упоминал??? Решение вполне себе работающее. Правда, автору придется думать что ж с этим решением делать дальше?
Ну передал в метод кусок данных с произвольной структурой. Дальше то что? А дальше нужно разбираться что ж там внутри, какие поля, какого типа, как к ним обращаться.. имена полей не будут так легко доступными.. повозиться придется! Может я чего-то не понимаю, но пользу от такой вот гибкости не очень-то видно, и объем кода получим не маленький.
Конечно, нужно смотреть на конкретную решаемую задачу. Но в общем случае, эффективнее не заморачиваться общими решениями с произвольными структурами данных. Всё-таки, в ABAPe при всех его странностях, очень даже приятно сделана интеграция кода со словарем данных и ошибки, связанные со словарем, хорошо ловятся уже при компиляции. )

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


[/quote]

еще один оффтоп:
Питон был приведен только как иллюстрация разного подхода к типизации в разных языках.

Я бы не стал обобщать так категорично.
Если есть 2 разных по структуре таблицы, в которых по одному алгоритму обрабатываются поля с одинаковыми именами, то лучше "заморочится" работой с произвольными структурами данных, чем работать методом copy-paste.

Продолжая оффтоп

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