Motivation
Who out of ABAP OO programmers is not bored to tears with endless declaring of internal tables. Firstly, decide the type: most folks use the standard, some go for sorted or hashed, always decisions, decisions. Then the key: what fields, unique, not unique, in those really rare cases where you have large amounts of data to process you may also consider a secondary key... All that not exactly in line with what usually an OO programmer would do. Take Java, .NET, AS3 or whatever OO environment you like. They all have, yes, what do they actually use if they do without such abundance of tables which are everything but OO?
Collections
In AS3, my favourite environment to show how simple yet brilliant OO can be, a collection can take mutliple forms: an array - a table of anything, a vector - a dense table of same objects or a dictionary where keys are subject to a strict comparison... All of that completely awkward in an ABAP OO environment. In ABAP OO terms, I'm talking double Dutch here.
So what? No collections in ABAP OO?
Nearly. However, if you spare a few minutes to have a look at the demo Vesna AOP application, you'll notice that the class ZLOGGER does not exactly use any kind of internal table for caching log entries. Instead, it hosts an attribute of type ref to /ARCONA1/ARRAY.
Generic array of stuff
/ARCONA1/ARRAY is a simple, generic collection of anything. It offers two modes: access by index or access by a key while the key is of string type. It's very, very simple.
Feel the simplicity
What can you store in such an array? Well, just about anything, really: a simple field, a structure, an internal table, a reference or an object. It behaves as close to any OO array as possible. In fact, /ARCONA1/ARRAY is an OO array. The best one you can have at this point. Developed, tested and improved continuously in Vesna Framework environment.
All right, so what is it good for?
Short answer: anything. Long version: you can use an OO array exactly in the same places where you'd be tempted to declare an internal table, with the only difference, it's OO. So you can use it like a stack or iterator:
Push
Add new items to the end of the array
Get next
Traverse the array (something like an OO loop)
Set by key
Insert anything into the array with a given key
Set by index
Insert anything into the array at specified index
Get with key
Retrieve an item for given key
Get with index
Retrieve an item for given position in the array
Other methods of the /ARCONA1/ARRAY class are of mostly internal use, like, e.g. in order to ensure its proper serialization.
How useful is it?
Very, very usefull. In any everyday programming context. You'll definitely notice immediately how your ABAP OO code becomes closer to a proper OO. It's unlikely that you'll be tempted to declare another internal table in your code, ever again.
I'd post some examples but I don't think it actually makes sense... All in all, if you read so far, you probably belong to this party of ABAP OO programmers who know exactly what collections are for and simply miss that functionality in NW ABAP dearly so I'm not going to bother you with things you're highly likely to already know.
All right, it's all nice, but how do I get it?
Vesna OO array is part of Vesna Framework. This is, however, neither the only nor the best reason to install it. Vesna gives you much more: Spring-like functionality for ABAP OO including AOP capabilities. If I got you interested, follow these links to get started:
Stay tuned to the next part of Vesna blog!