TABLE in a class

[Former Member]

I am new to ABAP, however I'd prefer to use ABAP objects if possible. Do I understand that a class cannot contain the TABLES keyword!!! If so what strategy do I use such that a class or instanciated object may own it's own data. In other words the class would query the database and the resultset would be exposed through an interface. I looked at persistence, but I don't think that would always be appropriate. What is the "best practice" in this case?

Message was edited by: EvilWonka

[nablan_umar]

Hi Michael,

In regular Abap, TABLES declarations is use to store the data you read from a database. For example:

TABLES: PA0001.

SELECT * from PA0001 where pernr = '1'.

endselect.

In this code, the results of the reading of table PA0001 will be store in structure PA0001.

In Abap object, you have to store your values into a defined variable/structure. So in object you should do something like this:

data: lv_pa0001 type pa0001.

select * into lv_pa0001 from pa0001 where pernr = '1'.

endselect.

[Former Member]

Nablan,

Thank you very much!!! My previous experience is with Java so I am trying to wade through all the documentation plus converting my Java object experience to ABAP. There seem to be fewer Object type examples as opposed to the procedural examples.

Aside from "ABAP OBJECTS" or SAP help, can you recommend another ABAP object resource such as ABAP programming for Java developers

[nablan_umar]

You can search in amazon.com on Abap objects books. Some of these books you can browse thru without actually buying it.

[Former Member]

Nablan,

Does ABAP have collection containers such as a Java Vector or Map?????

[horst_keller]

Hi,

some comments;

the TABLES statement is obsolete and should not be used any more, except for one single reason: as interface work area for exchanging data with Dynpros. For technical reasons, it is still necessary there.

Also outside ABAP Objects, TABLES should not be used to declare work areas for Open SQL statements and the short forms of Open SQL statements as shown in Nablan's answer (no INTO clause) should not be used either!

The reason is, that the TABLES statement is about eightfold overloaded and serves too much different purposes. It allows implicit behavior of many different statements, that make a program quiet obscure.

As for Open SQL, you shold always create work areas explicitly with DATA and fill them with the INTO clause.

The recommendation is, to put functional coding only into methods, because syntax constructs, that are declared as obsolete, are forbiddem there. The only reason, that the syntax is allowed outside classes is the downward compatibility of ABAP.

Regards

Horst

PS: Since ABAP is historically grown as a procedural language and ABAP Objects is an addon, we have in fact less object oriented concepts for things like strings or collections. Where Jave uses classes, ABAP mostly uses statements and concepts built in to the language. Instead of collections, ABAP offers internal tables (complex data objects with dynamic size).

[Former Member]

Horst,

Not so sure I understood this statement:

"The only reason, that the syntax is allowed outside classes is the downward compatibility of ABAP."

So, what your saying here is that ideally all the code "SHOULD" be in classes, but due to ABAPs procedural "nature" that is not done for compatibility reasons?

I also understood you to say that instead of collections, one should use internal tables! So I am assuming that one could instantciate an object (a class data type) and add it to an internal table.

Thank you very much for your comments.

[horst_keller]

Hi,

hmm, I didn't intend to say this, but in fact, ideally all the code "SHOULD" really be in classes!

What I wanted to say is, that we would like to have the same strict syntax rules inside and outside of classes, but we can't have that because ABAP must be downward compatible. We cannot invalidate existing coding by applying stricter syntax rules from release to release. The addition of classes gave us the chance to apply stricter rules at least in classes. The same is true for Unicode enabled programs.

In the syntax documentation (as of Release 6.40) you will find all syntax that we do not want to be used any more in a special section of obsolete statements. Most of them are syntactically forbidden in classes. Outside classes, you are not forced to discard such statements but you will get maximally a warning from the syntax check.

Therefore, when you code in (Unicode-enabled) classes, you automatically code according to the cleanest rules.

Regards

Horst

PS: Yes you can add objects (i.e. references to objects) to internal tables:

<b>DATA oref TYPE REF TI class.

DATA reftab TYPE TABLE OF REF TO class.

CREATE OBJECT oref TYPE class.

INSERT oref INTO TABLE reftab.</b>

[Former Member]

Horst,

I have been hearing that ABAP will be phased out and that Java will be the replacement. I am sure this has been discussed quite a bit, however how "imminent" or likely does this change appear to be????

[horst_keller]

Hi,

see "SAP NetWeaver for Dummies", page 237.

"ABAP is still an excellent choice as language for creating business applications".

I can't add anything to that ...

HK

[Former Member]

> PS: Yes you can add objects (i.e. references to

> objects) to internal tables:

>

> <b>DATA oref TYPE REF TI class.

> DATA reftab TYPE TABLE OF REF TO class.

> CREATE OBJECT oref TYPE class.

> INSERT oref INTO TABLE reftab.</b>

I seen that as:

<b>DATA lr_foobar TYPE REF TO CL_FOOBAR.

DATA lt_foobars LIKE TABLE OF lr_foobar.

CREATE OBJECT lr_foobar.

APPEND lr_foobar to lt_foobars.</b>