Helicopterview of ABAP [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.

---

开发者_StackOverflow

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 4 years ago.

Improve this question

I don't know a thing about ABAP, apart from it has an OO side, and I would like to have some kind of helicopterview of it before I start to look at it in detail. I know I can find all of this when studying it , but like I said for starters I like to know what I am dealing with.

• Is it (always) compiled?
• Typestem : Is it strongly typed? Does it use type inference?
• Inheritance : single / muliple, interface-like structures ?
• Collections : Has it collections apart from arrays ? Has it generic collections? Does it use List comprehension ?
• How about (con/contra/in)variance in arrays, returntypes, parametertypes, overriding?
• Any Exceptionhandling?
• Any build in design by contract support?
• Anything remarkable as oposed to other well known languages?
• ...

Any general info about characteristics basically would be welcome!

---

Is it (always) compiled?

ABAP is "compiled" into a sort of byte-code (called "load" for historical reasons) that is then executed by a virtual machine inside the kernel. You can compare this with Java, with one big difference: The load is not machine-independent, but optimized for the target machine type. This means that in a system landscape with several different types of application servers, you might have multiple pre-compiled loads for a single program. Not that you'll ever see any of this - the entire compilation process is handled automatically.

Typestem : Is it strongly typed? Does it use type inference?

Strongly typed with a system of generic types on top. Note that there's a complete data dictionary that is integrated into the language - very handy.

Inheritance : single / multiple, interface-like structures ?

Single inheritance. Interfaces are supported, including composite interfaces and implementation component renaming (two interfaces IF_FOO and IF_BAR can both define a method BAZ, and a class implementing both interfaces will then have two methods IF_FOO~BAZ and IF_BAR~BAZ).

Collections : Has it collections apart from arrays? Has it generic collections? Does it use List comprehension?

What you know as "array" in other programming languages does not really exist in ABAP - you'll usually use so-called "internal tables" instead. Think database-like structured in-memory tables. There are some ideas of collection classes spread out through different modules, but the canonical way to do this is to use internal tables - define a so called table type of lines that either represent references to instances or structures that contain such a reference.

How about (con/contra/in)variance in arrays, returntypes, parametertypes, overriding?

Arrays: see above. Overriding: You can not change the method signature when implementing interface method or overriding superclass methods. As for the parameters - that depends on whether you transfer data (or data references) or object references. In general, upcasting may happen implicitly while you have to perform the downcasting explicitly.

Any Exceptionhandling?

Yes. More than one way - again for the historical reasons (backward compatibility). Class-based exceptions are supported.

Any build in design by contract support?

None that I'm aware of.

Anything remarkable as oposed to other well known languages?

Lots of stuff. You might want to check http://www.volker-wegert.de/en/node/17 and http://www.volker-wegert.de/en/node/21 for an admittedly biased overview :-)

---

I'll try to provide some things the previous reply hasn't, while skipping what they did mention:

Is it (always) compiled?
Well, the interface for the programmer says "Activate", not compile, but that's because there is built in version management. When you Activate something, it compiles it, and makes the source and binary versions the "active" version. If someone tries to run source that isn't compiled, it will automatically be compiled as they run it.

Typestem : Is it strongly typed?
Basically, yes. ABAP is like a strange cross between Pascal and COBOL. There are "Field Symbols", which are like pointers. There are also now generic types. (And generic field pointers). One of the coolest things is that there is no difference between ABAP types and Database types. Any table you make will become a structure type automatically. That is to say, ABAP is integrated with the database in a way that almost no other languages are. You can also write SQL, which is actually part of the ABAP, as opposed to being just a string, like in other languages.

Inheritance : single / muliple, interface-like structures ?
There are interface structures, I don't usually use them. If you made a lot of re-usable classes, they would be a good idea, though.

Collections : Has it collections apart from arrays ? Has it generic collections? Does it use List comprehension ?
Better, it has "Internal tables", which are basically a type of dynamic array. They can be declared from almost any type, including those in the data dictionary. They can be looped, sorted, etc. There are several types, including hashed and sorted variants.

Any Exception handling?
Both OOP and non-OOP types.

Anything remarkable as oposed to other well known languages?
As the other poster said, a lot. It is very good at anything to do with database operations, and re-using complex structures and data types. It is naturally is cross-database and cross-platform (OS, and processor). It has a very good version management and transport system. The whole SAP system has very good multi-language support. You can get simple screens with appropriate titles and selection boxes automatically, which means that you can do less programming and more work. You don't have to map between DB types and language types, etc.
Things it's less than good at:
1. Numbers are typically stored as ASCII, this makes it less than fast at math in many applications.
2. Most of the data structures are very normalized, meaning your data may be spread across 50 tables sometimes. "Star" queries are very common. Built in functions to retrieve data (f.e. Logical Databases) are your friend in those cases.
3. SAP tried to be everything to everyone, so there are a lot of configuration options, etc., and sometimes a function doesn't do what you expected it to based on past behavior.
4. ABAP is sometimes very verbose. Try using the "pattern" button on something simple like GUI_DOWNLOAD.
5.SAP was very ambitious with what they took on, and thus ran into limitations of hardware, operating systems, and RDBM systems early-on. Thus, they have legacy kludges to deal with it that aren't pretty. (Pool Tables, Cluster tables, etc.)
6. When you activate a program, it doesn't do full compatibility checking with the function modules used. There are situations where something will activate with no problem, but then crash at run-time, even in cases where it could have been caught at compile time.