Abap News for Release 740 Inline Declarations

7/25/2019 Abap News for Release 740 Inline Declarations

1/35

Generated by Jive on 2016-05-25+02:00

1

ABAP Development: ABAP News for Release7.40 - Inline Declarations

Posted by Horst Keller23 May, 2013Inline declarations are a new way of declaring variables and field symbols at operand positions.

Data Declarations

In ABAP you have many operand positions, where the value of the operand is changed by the statement. The

most typical of these "write positions" is the left hand side lhs of an assignment.

lhs = rhs.

But of course there are more. The data objects you can use at these write positions are either writable formal

parameters of the procedure you are working in or variables declared with DATA in front of the statement.

In many cases the variables filled by a statement are helper variables that you only need close to the

statement. For each of these helper variables you had to write a data declaration with the DATA statement and

of course it was your task to give the variable an adequate type.

Well, the operand type of most write positions is statically fixed and well known to the compiler. And this is why

ABAP can offer inline data declarations with Release 7.40. The ingredients are so called declaration positions

(write positions with fully known operand type) and the new declaration operator DATA(...).

Let's look at some examples.

Declaration of a lhs-variable for a simple assignment

Before 7.40

DATA text TYPE string.

text = `...`.

With 7.40

DATA(text) = `...`.
http://scn.sap.com/people/horst.keller


2/35

ABAP Development: ABAP News for Release 7.40 - Inline Declarations


2

Declaration of table work areas

Before 7.40

DATA wa like LINE OF itab.

LOOP AT itab INTO wa.

...

ENDLOOP.

With 7.40

LOOP AT itab INTO DATA(wa).

...

ENDLOOP.

Declaration of a helper variable

Before 7.40

DATA cnt TYPE i.

FIND ... IN ... MATCH COUNT cnt.

With 7.40

FIND ... IN ... MATCH COUNT DATA(cnt).

Declaration of a result

Before 7.40

DATA xml TYPE xstring.


3/35



3

CALL TRANSFORMATION ... RESULT XML xml.

With 7.40

CALL TRANSFORMATION ... RESULT XML DATA(xml).

Declaration of actual parameters

Before 7.40

DATA a1 TYPE ...

DATA a2 TYPE ...

oref->meth( IMPORTING p1 = a1 IMPORTING p2 = a2

... )

With 7.40

oref->meth( IMPORTING p1 = DATA(a1)

IMPORTING p2 = DATA(a2)

... ).

Declaration of reference variables for factory methods

Before 7.40

DATA ixml TYPE REF TO if_ixml.

DATA stream_factory TYPE REF TO if_ixml_stream_factory.

DATA document TYPE REF TO if_ixml_document.

ixml = cl_ixml=>create( ).

stream_factory = ixml->create_stream_factory( ).

document = ixml->create_document( ).

With 7.40


4/35



4

DATA(ixml) = cl_ixml=>create( ).

DATA(stream_factory) = ixml->create_stream_factory( ).

DATA(document) = ixml->create_document( ).

This exampleis my favorite. When working with class libraries as the iXML-Library you don't have to careabout the data type of the reference variables too much any more. You simply create them inline and use them.

As you will see in the 7.40 version of the ABAP Example Library, this feature has facilitated my writings of

example programs considerably.

Field Symbols

For field symbols there is the new declaration operator FIELD-SYMBOL(...) that you can use at exactly three

declaration positions.

ASSIGN ... TO FIELD-SYMBOL().

LOOP AT itab ASSIGNING FIELD-SYMBOL().

...

ENDLOOP.

READ TABLE itab ASSIGNING FIELD-SYMBOL() ...

I guess it is clear to you what happens here.

Outlook

In my upcoming blogs I will make use of inline declarations when introducing other new features. Be prepared

for code like this:

TYPES t_itab TYPE TABLE OF i WITH EMPTY KEY.

DATA(itab) = VALUE t_itab( ( 1 ) ( 2 ) ( 3 ) ).

Yes, this is ABAP 7.40 ...

37576 Views Tags: abap

Horst Kellerin response to Marc Cawoodon page 5
http://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/community/abap/blog/tags#/?tags=abap


5/35



5

6 Feb, 2016 10:49 AM

Check out the places where DATA(...) is possible here.

Marc Cawoodin response to Horst Kelleron page 5

6 Feb, 2016 10:31 AM

OK, I get the CHANGING argument - not the inline one since I use CONV successfully for EXPORTING

parameters.

One more for you - should this not work?

DATA ls_ret TYPE zmytype.

APPEND ls_ret TO data( lt_ret ).

Is lt_ret not implicitly TYPE STANDARD TABLE OF zmytype?

It seems to me this is corollary of LOOP AT itab INTO DATA(wa)


6 Feb, 2016 10:17 AMThere are several reasons, CONV is not an inline declaration, CHANGING is neither a declaration position nor

general expression position. How should that work at a read/write position?

Marc Cawood

6 Feb, 2016 9:31 AM

Any idea why this doesn't work?

/ui2/cl_json=>deserialize(

EXPORTING json = request->get_cdata( )

CHANGING data = CONV zmy_data_tt( lt_data )

).

Instead of declaring DATA lt_data TYPE zmy_data_tt.

Vinoth Kumar

3 Feb, 2016 2:07 PM

Great Horst, Amazing features!!!

Awaited for such facility for a very long time..

Feeling excited

Mike Pokrakain response to Mike Pokrakaon page 6

3 Feb, 2016 2:02 PM

Actually I've just thought about it some more and it could be a risk if one isn't careful:

loop at itab into data(wa).

...

if some condition.

read table things into data(wa).

==> oops!
http://scn.sap.com/people/vino.zenonhttp://scn.sap.com/people/marc.cawoodhttp://scn.sap.com/people/mike.pokrakahttp://scn.sap.com/people/mike.pokrakahttp://scn.sap.com/people/vino.zenonhttp://scn.sap.com/people/vino.zenonhttp://scn.sap.com/people/marc.cawoodhttp://scn.sap.com/people/marc.cawoodhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/marc.cawoodhttp://scn.sap.com/people/marc.cawoodhttp://help.sap.com/abapdocu_750/en/index.htm?file=abendeclaration_positions.htm


6/35



6

...

endloop.

But then again this is down to the developer to manage. The same mistake is possible with a regular DATA

declaration up front.

Mike Pokrakain responseto Horst Kelleron page 6

3 Feb, 2016 1:53 PM

Understood, and that is exactly how an old-style DATA statement works.

But, since 'it will never do', can/should an inline DATA not be made more tolerant and just be local to the

method all the time?

If a global element of the same name already exists, it will be overshadowed (current behaviour).

If a local declaration (method, function module) already exists, the same element will be reused - as if the

data() statement were not there.

Just an idea that, to me at least, makes more sense than ever with inline declarations.

Horst Kellerin response to Mike Pokrakaon page 6

3 Feb, 2016 1:32 PM

I'd rather say big annoyance. An inline declaration is like a DATA statement at this position with all well known

drawbacks. But as already discussed here from time to time, ABAP does not support local data contexts in

control structures and I'm afraid it will never do.

Mike Pokraka

3 Feb, 2016 1:18 PM

Small annoyance: Why are multiple inline declarations not permitted in the same block? Would it not makesense to just ignore something that's already declared and reuse it?

My main use case is an inline declaration that can be conditional and/or inside a loop.

if some condition.

read table x into data(wa) index 1.

endif.

...

if some other condition.

read table x into data(wa) where ...endif.

It just seems awkward to have to use wa1 and wa2 here.

Regards,

Mike

Horst Kellerin response to Suhas Sahaonpage 7
http://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/mike.pokrakahttp://scn.sap.com/people/mike.pokrakahttp://scn.sap.com/people/mike.pokrakahttp://scn.sap.com/people/mike.pokrakahttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/mike.pokrakahttp://scn.sap.com/people/mike.pokrakahttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/mike.pokrakahttp://scn.sap.com/people/mike.pokraka


7/35



7

3 Feb, 2016 11:09 AM

way more than you think ...

Suhas Sahain response to Paul Hardyon page 9

3 Feb, 2016 11:06 AM

I suppose that is why, when you pass the wrong type of variable into a function module, the

normal syntax check doesn't say boo, but you get a short dump when you run the program.

I always wondered, why do FMs get such love from the syntax checker? Now i know

Suhas Sahain response to Horst Kelleron page 8

3 Feb, 2016 11:04 AM

A true story that happened to me: I changed the interface of a method of CL_ABAP_DOCU

and forgot to adjust its callers before activating.

Good to know Horst Kelleralso makes mistakes

Horst Kellerin response to Paul Hardyon page 7

3 Feb, 2016 10:45 AM

In fact you can add this new syntax check warning and ditch the "work area has more fields"

one if you want.

Unfortunately (or maybe fortunately) Ican't

Paul Hardyin response to Horst Kelleron page 8

3 Feb, 2016 10:37 AM

I understand that SAP tries to be 100% downward compatible i.e. an upgrade will cause very few syntax errorsto existing code. I have usually found if custom code passes the extended syntax check then you are very safe

indeed,

However in the past I have found that after an upgrade some custom code shows a yellow warning in the

standard syntax check, where it did not on the old version of ABAP.

As a fine example, the most annoying thing in the world "work area has more fields than selected".

Show me a bus queue of programmers who thought that was a wonderful innovation.

If SAP were to add a yellow warning "your function module is going to dump, and here is why" it would not

cause syntax errors in any oldcode, which would continue to behave as before (dump) and not cause any grief

being being transported or whatever.

In fact you can add this new syntax check warning and ditch the "work area has more fields" one if you want.
http://scn.sap.com/people/paul.hardy2http://scn.sap.com/people/paul.hardy2http://scn.sap.com/people/paul.hardy2http://scn.sap.com/people/suhas.sahahttp://scn.sap.com/people/paul.hardy2http://scn.sap.com/people/paul.hardy2http://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/suhas.sahahttp://scn.sap.com/people/suhas.sahahttp://scn.sap.com/people/suhas.sahahttp://scn.sap.com/people/suhas.saha


8/35



8

Oh yes, and in regard to the current situation ... it's a bug, bug, bug, bug, bug.

Horst Kellerin response to Suhas Sahaon page 9

3 Feb, 2016 10:37 AM

Is this somewhere specified in the ABAP documentation?

See CALL FUNCTION ...

(And the the last point here, hehe)


3 Feb, 2016 10:34 AM

In theory, yes. But good ol' function modules are "different".

Remember, there's no ABAP syntax for defining a function module's interface as it is for methods.


3 Feb, 2016 10:26 AM

In theory you (ABAP Product Management) could make a new keyword (or syntax variant) to call FMs

"strongly".

EXEC FUNCTION 'MYFUNC'.

or

CALL FUNCTION MYFUNC. " Instead of 'MYFUNC'

It's always been a weaknes of FMs that theycompile when they're definitely gonna dump.


3 Feb, 2016 10:21 AMI suppose that is why, when you pass the wrong type of variable into a function module, the

normal syntax check doesn't say boo, but you get a short dump when you run the program.

And if a function module has three compulsory IMPORTING parameters and I only specify

two, no syntax error either.

Yes,, sure ...

I will now be told millions of reasons

One important reason is, its too old to be changed. There are miilions lines of code lying around worldwide that

call FMs wrongly but are never executed (dead, dead, dead), Now you go and make syntax errors out of that

and have some fun.

In fact, there are also fans of the lax checking. The reason is that you do not break a system if you change

an interface in an incompatible way as you do with methods. A true story that happened to me: I changed the

interface of a method of CL_ABAP_DOCU and forgot to adjust its callers before activating. As result callers

became syntactically incorrect and since CL_ABAP_DOCU is called far deeper in the system than I ever

expected, you could not logon to the system any more due to syntax errors in central modules. Unfortunately,
http://scn.sap.com/people/horst.kellerhttp://help.sap.com/abapdocu_750/en/index.htm?file=abenoperands_specifying.htmhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/marccawoodhttp://scn.sap.com/people/marccawoodhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://help.sap.com/abapdocu_750/en/index.htm?file=abenoperands_specifying.htmhttp://help.sap.com/abapdocu_750/en/index.htm?file=abapcall_function_general.htmhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.keller


9/35



9

there was a customer presentation running on that system in SAP Arena, Mannheim that afternoon - no lie!

The presenter wasn't amused. And correcting the error also wasn't to simple (remember, no logon possible).

Admin had to import the old version of the class. Wouldn't have happened with a function module. I am not a

fan of lax checking but had to learn to be more careful the hard way.

Paul Hardyin response to Suhas Sahaon page 9

3 Feb, 2016 9:57 AM

I suppose that is why, when you pass the wrong type of variable into a function module, the normal syntax

check doesn't say boo, but you get a short dump when you run the program.

And if a function module has three compulsory IMPORTING parameters and I only specify two, no syntax error

either.

I know function modules are obsolete now, and we should not be using them, but I have always thought

this (lack of syntax check warnings) was a bug as opposed to anything else i.e. too difficult for SAP to fix so

document it, and then pretend it is not a bug. To be fair Microsoft do this sort of thing all the time.

It is rather like the FOR ALL ENTRIES with a blank table doing a full table scan as opposed to not bringing

back anything. That is an obvious bug as well, but will never be fixed, just more and more code inspector

warnings.

I am sure I will now be told millions of reasons why the code inspector / extended syntax check can do this, but

not the standard syntax check, that's impossible, to whichI will reply "it's a bug, bug, bug, bug, bug"

Suhas Sahain response to Horst Kelleron page 9

3 Feb, 2016 9:31 AMProblem is that calling a function module other than calling a method is always a dynamic

call. You specify the function module as a field and never directly.

Wow!!! Made my day

Is this somewhere specified in the ABAP documentation? I mean although this (You specify the function

module as a field) is quite obvious, but still most of the ABAPers wouldn't have thought about it


3 Feb, 2016 8:33 AMHow do you mean "constructor"?

I mean constructor expression.

Theoretically, if the parameters of a Function Module are strongly typed then the compilercanknow the type...
http://help.sap.com/abapdocu_750/en/index.htm?file=ABENCONSTRUCTOR_EXPRESSION_GLOSRY.htmhttp://scn.sap.com/people/suhas.sahahttp://scn.sap.com/people/paul.hardy2http://help.sap.com/abapdocu_750/en/index.htm?file=ABENCONSTRUCTOR_EXPRESSION_GLOSRY.htmhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/suhas.sahahttp://scn.sap.com/people/suhas.sahahttp://scn.sap.com/people/paul.hardy2http://scn.sap.com/people/paul.hardy2


10/35



10

Problem is that calling a function module other than calling a method is always a dynamic call. You specify the

function module as a field and never directly. The compiler doesn't know the function module.Specifying it with

a literal is pseudo static so to say. Then, some test tools (extended program check) evaluate the name, but not

the compiler.


3 Feb, 2016 8:08 AM

How do you mean "constructor"?

Theoretically,if the parametersof a Function Module are strongly typed then the compiler can know the type...


1 Feb, 2016 4:55 PM

See EXPORTING:

a1, a2, ... are general expression positions. In other words, functions and expressions canbe passed as actual parameters, alongside data objects.

-> You can pass your myStringMethod( ).

Unlike in , types cannot be specified generically (#) when a is specified. This is because the

typing of the parameters is not determined until runtime.

-> That's why you have to specify type string explicitly (or call a method).

Marc Cawoodin response to Marc Cawoodon page 10

1 Feb, 2016 3:43 PM

OK, gottit:

CALL FUNCTION 'LOAD_SOMETHING'

EXPORTING

customer = CONV kunnr( get( 'customer' ) )

Pretty cool - ABAP arrivoing in the 21st century at last!

Shai Sinaiin response to Marc Cawoodon page 10

1 Feb, 2016 2:41 PM

Do you mean CONV (ABAP News for Release 7.40 - Constructor Operators CONV and CAST)?

You must set the expected type explicitly though.

Marc Cawood

1 Feb, 2016 2:33 PM

Any way to dynamically cast inbound parameters of FUNCTION modules?

DATA: lv_s TYPE STRING VALUE '0000'.
http://scn.sap.com/people/marccawoodhttp://help.sap.com/abapdocu_750/en/index.htm?file=abapcall_function_parameter.htmhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/marccawoodhttp://scn.sap.com/people/marccawoodhttp://scn.sap.com/people/marccawoodhttp://scn.sap.com/community/abap/blog/2013/05/27/abap-news-for-release-740--constructor-operators-conv-and-casthttp://scn.sap.com/people/shai.sinaihttp://scn.sap.com/people/shai.sinaihttp://scn.sap.com/people/marccawoodhttp://scn.sap.com/people/marccawoodhttp://help.sap.com/abapdocu_750/en/index.htm?file=abapcall_function_parameter.htmhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/marccawoodhttp://scn.sap.com/people/marccawood


11/35



11

CALL FUNCTION SOMETHING

EXPORTING vkorg = lv_s. " Dumps here expecting CHAR4

or even better:

CALL FUNCTION SOMETHING

EXPORTING vkorg = myStringMethod( ). " Function returning string

Currently the compiler says "No type can be derived from the context for the operator "CONV"."

Horst Kellerin response to Dionisio Ambronaon page 11

19 Sep, 2015 6:12 PM

Is there any rule so the system determines this?

Sure, see the ABAP Keyword Documentation...

In the above example you have a string literal on the RHS and therefore the result is string.

Best,

Horst

Dionisio Ambrona

12 Sep, 2015 8:49 PM

Dear Horst Keller,

in a first place, thanks a lot for your blog. I'm just starting to learn about new ABAP 7.40 capabilities, so I find

it quite usefull and interesting.

Regarding your first example in this post,

Before 7.40

DATA text TYPE string.

text = `...`.

With 7.40

DATA(text) = `...`.
http://scn.sap.com/people/dionisio.ambronahttp://scn.sap.com/people/dionisio.ambronahttp://scn.sap.com/people/dionisio.ambronahttp://help.sap.com/abapdocu_740/en/index.htm?file=abapmove.htmhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.keller


12/35



12

I have the following question: what is the data type in the second dclaration with 7.40, is it a type string

variable or is it a type c variable? Is there any rule so the system determines this?

I know by reading the blog that online declarations are specially meant to be used for calling methods

avoding extra code lines to declare help variables, but I'm just curious.

Thank you and best regards!

Dionisio

Jose Antonio Blanco de Cordova Diaz-Madroero

4 Jul, 2015 12:23 PM

I am full of happiness. Functional programming at last

Horst Kellerin response to Sudhi Karkadaon page 12

3 Jul, 2015 8:15 AM

Works as before, eg.,

DATA struct1 TYPE scarr.

DATA(struct2) = VALUE scarr( ).

... struct1 ...

... struct2 ...

Double clicking struct1, struct2 leads to the respective declaration, where you can double click the type.

Sudhi Karkada

2 Jul, 2015 7:16 PM

Thanks for the article and for introducing us to new ABAP.

I am sorry if this question was already asked and answered in the 5 pages of Q&A, but how does the double-

click navigation work with this type of inline declarations? If the variable is a structure, would I be able to

eventually navigate (just by double-clicking a few times) to DDIC and see the structure components?

When I first started programming, many languages were sneered at because they did not require explicit data

declarations. Agreed, inline declaration is different, but still the trend is unsettling.

Horst Kellerin response to Raphael Pachecoon page 13

2 Jul, 2015 6:38 PM

Would it be possible to write, for example, ADD 1 to DATA(i)?
http://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/sudhi.karkadahttp://scn.sap.com/people/sudhi.karkadahttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/joseantonio.blancodecordovadiaz-madroerohttp://scn.sap.com/people/joseantonio.blancodecordovadiaz-madroero


13/35



13

No, for two reasons:

The statement ADD is not expression enabled.

DATA(num) = num + 1 doesn't work either because you cannot declare a variable inline at LHS thatis used at RHS.

Best

Horst

Raphael Pacheco

2 Jul, 2015 6:22 PM

Horst,

I have a basic question of this inline declarations.

How could I create a counter using the inline declarations? It would be possible to make, for example ADD 1 to

DATA(i)?

Warn regards,

Raphael Pacheco.

Michael Fritzin response to Nishant Bansalon page 13

4 May, 2015 7:47 AM

Hi,

no you can't use DATA(wa) again.

However after writing this inline declaration above, you can now use


...

ENDLOOP.

anywhere in your coding. No need to declare wa again.

Michael

Nishant Bansal

4 May, 2015 7:30 AM

Dear Horst Keller,

First of all thanks for sharing this blog.
http://scn.sap.com/people/nishant.bansalhttp://scn.sap.com/people/nishant.bansalhttp://scn.sap.com/people/michael.fritzhttp://scn.sap.com/people/michael.fritzhttp://scn.sap.com/people/raphael.almeidahttp://scn.sap.com/people/raphael.almeida


14/35



14

I have one question regarding this. Below i am taking one simple example.

DATA wa like LINE OF itab.


...

ENDLOOP.

With 7.40

LOOP AT itab INTO DATA(wa).

...

ENDLOOP.

After definingthe WA using DATA(WA).

Can i define the same name WA variable again in the current session?

Actually i don't have system to test it.

Thanks and Regards,

Nishant

Sougata Chatterjeein response to Sougata Chatterjeeon page 14

4 May, 2015 3:46 AM

Sorry, I take that back - it does work for exporting params. Thanks!

Sougata Chatterjeein response to Rdiger Plantikoon page 14

4 May, 2015 3:04 AM

Thanks but it will not work for me as I'm on SP05.

Rdiger Plantikoin response to Sougata Chatterjeeon page 15

3 May, 2015 5:33 PM

Hi Sougata,

you want to pass a data object to the called function module, where it will not be changed (since you are

EXPORTING it).

The only case where this makes sense in my eyes would be that the inventor of the function module declared

an import parameter to be obligatory although not strictly needed in the code (i.e. although being optional in

fact), and you want to pass an initial value to it, just to satisfy the interface.

You can't do that with a DATA operator, but you could do it with VALUE:
http://scn.sap.com/people/rdiger.plantiko2http://scn.sap.com/people/sougata.chatterjeehttp://scn.sap.com/people/sougata.chatterjeehttp://scn.sap.com/people/sougata.chatterjeehttp://scn.sap.com/people/sougata.chatterjeehttp://scn.sap.com/people/rdiger.plantiko2http://scn.sap.com/people/rdiger.plantiko2http://scn.sap.com/people/sougata.chatterjeehttp://scn.sap.com/people/sougata.chatterjeehttp://scn.sap.com/people/sougata.chatterjeehttp://scn.sap.com/people/sougata.chatterjee


15/35



15

call function 'Z_IMPORT_PAR_OBLIGATORY'

exporting

is_vbap = value vbap( ).

Here, IS_VBAP is an obligatory import parameter of Z_IMPORT_PAR_OBLIGATORY of type VBAP. You

can't use # here, because for function modules - as opposed to methods - the compiler doesn't re-read the

parameter types.

Regards,

Rdiger

Horst Kellerin response to Sougata Chatterjeeon page 15

2 May, 2015 5:53 PM

Since that operand position isa read and not a write position. Declaration positions are always write positions

(L-values, not R-values).

Sougata Chatterjee

2 May, 2015 1:02 PMHi Horst,

Why the following is not supported? I'm in 7.4 SP05 on HDB - is it supported in later SPs?

CALL FUNCTION 'function_module'

EXPORTING

i_param = DATA(lv_data)

Regards,

Sougata.

Dominik Krmerin response to Horst Kelleron page 15

8 Apr, 2015 7:45 PM

Thanks for the explanation.

However it's a shame that the runtime would give me the expected result and then have the limitation in the

compiler, as I would had a use case for this which would have saved me a ton of additional declaration.

Regards,

Dominik

Horst Kellerin response to Dominik Krmeron page 168 Apr, 2015 5:06 PM

Debugger is runtime. A DESCRIBE FIELD or RTTI would also find the internal table.

But syntax check happens at compile time and the internal table cannot be deduced statically.
http://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/dominik.kraemer%40outlook.comhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/dominik.kraemer%40outlook.comhttp://scn.sap.com/people/dominik.kraemer%40outlook.comhttp://scn.sap.com/people/sougata.chatterjeehttp://scn.sap.com/people/sougata.chatterjeehttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.keller


16/35



16

https://ldcialx.wdf.sap.corp:44318/sap/public/bc/abap/docu?sap-language=EN&sap-

client=000&format=STANDARD&object=ABENTYP

"The formal parameter or field symbol can be used as operands anywhere that is

not excluded by this typing. However, operands that expect particular internal

tables are an exception to this rule. Here, only formal parameters or field

symbols typed as internal tables with the appropriate table category are allowed."


8 Apr, 2015 4:45 PM

Hi Horst,

not sure if I fully understood your point.

In the debugger the type is correctly deduced as Sorted Table, only in the ABAP editor this is not recognised /

throws the error message: "." expected after ""

Regards,

Dominik

Horst Kellerin response to Dominik Krmeron page 17

8 Apr, 2015 4:21 PM

If no type can be deduced, the field symbol declared inline is typed with ANY. You never could/can use fully

generic field field symbols at operand positions of internal tables. That's the rule.

Horst Kellerin response to Horst Kelleron page 17

8 Apr, 2015 4:15 PM

The nonsense is independent from expressions
http://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/dominik.kraemer%40outlook.comhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/dominik.kraemer%40outlook.comhttp://scn.sap.com/people/dominik.kraemer%40outlook.comhttps://ldcialx.wdf.sap.corp:44318/sap/public/bc/abap/docu?sap-language=EN&sap-client=000&format=STANDARD&object=ABENTYPING_GENERIC&tree=Xhttps://ldcialx.wdf.sap.corp:44318/sap/public/bc/abap/docu?sap-language=EN&sap-client=000&format=STANDARD&object=ABENTYPING_GENERIC&tree=X


17/35



17

FIELD-SYMBOLS TYPE any.

DATA wa.

LOOP AT INTO wa.

...

ENDLOOP.


8 Apr, 2015 4:15 PM

Yes that's my workaround for the moment. Is this something which is planned for a later release, or are there

any technical restrictions which prevent this?

Regards,

Dominik

Horst Kellerin response to Dominik Krmeron page 17

8 Apr, 2015 4:04 PM

The error message is nonsense (I forward it) but you are trying to loop over something that can't be statically

recognized astable. For that you still need a explicit declaration:

FIELD-SYMBOLS type STANDARD TABLE.

ASSIGN COMPONENT 'SCARR' OF STRUCTURE flights TO .

LOOP AT ASSIGNING FIELD-SYMBOL().

...

ENDLOOP.

Dominik Krmer

8 Apr, 2015 3:55 PM

Hi Horst,

great blog! However I have an question on the following part:

TYPES: t_scarr TYPE SORTED TABLE OF scarr

WITH UNIQUE KEY carrid.

TYPES:

BEGIN OF t_flights,

scarr TYPE t_scarr,

END OF t_flights.
http://scn.sap.com/people/dominik.kraemer%40outlook.comhttp://scn.sap.com/people/dominik.kraemer%40outlook.comhttp://scn.sap.com/people/dominik.kraemer%40outlook.comhttp://scn.sap.com/people/dominik.kraemer%40outlook.comhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/dominik.kraemer%40outlook.comhttp://scn.sap.com/people/dominik.kraemer%40outlook.com


18/35



18

DATA: flights TYPE t_flights.

SELECT * FROM scarr INTO TABLE flights-scarr.

ASSIGN COMPONENT 'SCARR' OF STRUCTURE flights TO FIELD-SYMBOL().

Basically the above code works like a charm and in the end the fs_dt_data contains a sorted table with the

values from scarr. However when I then want to do a loop over this table I cannot get the code to be activated:


...

ENDLOOP.

I always receive the following error: "." expected after ""

Is this a bug or am I doing something wrong?

Regards,

Dominik

Horst Kellerin response to Rajan Singhon page 18

11 Mar, 2015 7:47 AM

Same, because the same kernel modules are called. It's mainly the syntax that is different.

But be aware of performance traps if you use expressions repeatedly in statements or even in loops. The new

syntax can be seductive to write things you never wrote with fully blown statements. That can easlily lead to

performing the same operations multiply.

Horst Kellerin response to Michael Fritzon page 19

11 Mar, 2015 7:43 AM

TYPES: tt_w3head type STANDARD TABLE OF w3head WITH ... KEY ...

DATA(data: lt_w3head) = VALUE #( ).

but see above,

... the question remains, why you want to do this at all? ... The DATA operator for inline

delcarations is designed for being used at declaration positions where the operand type is

completely known and not for declaring variables of any types before using them.

See Declaration positions

Rajan Singh

11 Mar, 2015 7:39 AM

Hello Horst,

The new features of ABAP are exciting. Is the performance same or better compared to old ones?
http://scn.sap.com/people/damandeep.thakur2http://help.sap.com/abapdocu_740/en/index.htm?file=abendeclaration_positions.htmhttp://scn.sap.com/people/damandeep.thakur2http://scn.sap.com/people/damandeep.thakur2http://help.sap.com/abapdocu_740/en/index.htm?file=abendeclaration_positions.htmhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.keller


19/35



19

Thanks!

Michael Fritz

10 Mar, 2015 4:06 PM

You see I'm still learning those new inline declarations since we recently upgraded our ERP to 7.40 (SP08)

I wonder how to create an internal table without using any default values.

Previously I would have written a statement like this:

data: lt_w3head type STANDARD TABLE OF w3head.

Now I tried to get the same result using inline declaration, to no avail so far.

I need this internal table as a result table for a function module, hence I don't have any rows available so far.The function module will return them instead.

Would it be possible to use those inline declarations for this purpose, too?

Michael


10 Mar, 2015 9:40 AM

That means it does not matter if the IF condition is met or not and the program

execution immediately jumps into the ELSE branch?

Yes, but that's also kind of dangerous. Because there is no local context for data in control structures, the

declared objects are statically visible everywhere behind the declaration and dynamically (ASSIGN (name ) ...)

even everywhere in front of the declaration. Therefore, it needs some discipline when working with that, see the

guideline.

Michael Fritzin response to Horst Kelleron page 20

10 Mar, 2015 9:34 AM

Horst,

thanks again for your reply.

That means it does not matter if the IF condition is met or not and the program execution immediately jumps

into the ELSE branch?

That's cool indeed!
http://scn.sap.com/people/michael.fritzhttp://scn.sap.com/people/michael.fritzhttp://scn.sap.com/people/michael.fritzhttp://help.sap.com/abapdocu_740/en/index.htm?file=abendeclaration_inline_guidl.htmhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/michael.fritzhttp://scn.sap.com/people/michael.fritz


20/35



20

I've just checked this and it works perfectly! Never thought of this! At the very end no short dumps or similar

when accessing the reference from the ELSE branch.

Thanks,

Michael


10 Mar, 2015 8:38 AM

Well that's simple

IF NOT l_notif_no ISINITIAL .

DATA(o_reference) = NEW zcl_customer_service_base(

i_order_number = ''

i_notif_number = l_notif_no

i_use_notification = abap_true

i_no_notif_buffer = abap_false

i_no_partner_init = abap_true

i_remove_deleted_items = abap_true

).

ELSE.

o_reference = me. "


21/35



21

IF NOT notif_no IS INITIAL.

"Create new reference

CREATE OBJECT o_reference

EXPORTING

i_order_number = ''i_notif_number = l_notif_no




i_remove_deleted_items = abap_true.

ELSE.

"Use existing reference

o_reference = me.

ENDIF.

The following will not work because of error "o_reference is already declared" when using the second inline

declaration in the ELSE branch.

IF NOT l_notif_no IS INITIAL .

DATA(o_reference) = NEW zcl_customer_service_base(

i_order_number = ''

i_notif_number = l_notif_no




i_remove_deleted_items = abap_true

).

ELSE.

DATA(o_reference) = me. "


22/35



22

DATA(val) = get_packed( ... ).

This is a use case. Constructs as above are possible but more as side effects ...

Horst Kellerin response to Adi Siekeron page 2223 Feb, 2015 8:21 AM

The problem is, it wouldn't work too. Syntax error in:

TYPES pack TYPE p DECIMALS 3.

DATA(val) = VALUE pack( '1.1' ).

Why? Operator VALUE is not possible for elementary types except for the initial value.

Therefore, either initial value:


DATA(val) = VALUE pack( ).

or the conversion operator:


DATA(val) = CONV pack( '1.1' ).

But in fact the question remains, why you want to do this at all?

If you want to declare a packed number, simply do so by using statement DATA or TYPES. The DATA operator

for inline delcarations is designed for being used at declaration positions where the operand type is completely

known and not for declaring variables of any types before using them. So if you have e.g. a method retrurning a

packed number, of course you write

DATA(val) = get_packed( ... ).

This is a use case. Constructs as above are possible but more as side effects ...

Adi Siekerin response to Amol Vakhareon page 22

22 Feb, 2015 10:18 PM

Hi,

I would use a type from the data dictionary.

Cheers

Adi
http://scn.sap.com/people/adi.siekerhttp://scn.sap.com/people/adi.siekerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.keller


23/35



23

Amol Vakharein response to Adi Siekeron page 23

22 Feb, 2015 2:37 PM

Hi Adi,Though I understood the use of VALUE.. still wondering why following gives compile time error>

Data(lv_var) = value p('123.10').

Error: Value of generic type "P" cannot be constructed..

The documentation says for generic type, additional attributes need to be specified.. so stuck again? Probable

alternate is to define a type with a packed component in it and use it to declare.. Thoughts?

Amol Vakharein response to Adi Siekeron page 23

22 Feb, 2015 1:42 PM

Thanks Adi! Understood the use of VALUE too

Adi Siekerin response to Amol Vakhareon page 2322 Feb, 2015 1:38 PM

Hi Amol,

DATA(lv_var2) = VALUE packed_type('1.10').

Where packed_type is any type in the ABAP dictionary and whatever else VALUE allows.

Cheers

Adi

Amol Vakhare22 Feb, 2015 1:23 PM

Hi Horst,

Wondering how can I declare a packed variable or any other type variable using the Data() operator.

Data(lv_var1) = 1. "Integer"

Data(lv_var2) = '1.10'. "Declared as character...

How to declare lv_var2 as packed type?

Horst Kellerin response to Adi Siekeron page 23

19 Feb, 2015 2:50 PM

Can I like that twice

Give me five!

Adi Siekerin response to Horst Kelleron page 24

19 Feb, 2015 2:44 PM
http://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/amolvakharehttp://scn.sap.com/people/amolvakharehttp://scn.sap.com/people/amolvakharehttp://scn.sap.com/people/adi.siekerhttp://scn.sap.com/people/adi.siekerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/amolvakharehttp://scn.sap.com/people/amolvakharehttp://scn.sap.com/people/adi.siekerhttp://scn.sap.com/people/adi.siekerhttp://scn.sap.com/people/amolvakharehttp://scn.sap.com/people/amolvakharehttp://scn.sap.com/people/amolvakharehttp://scn.sap.com/people/amolvakhare


24/35



24

Horst Keller wrote:

Arrrrrgh

Can I like that twice.

oh, and btw space is getting pretty thin down this deep in a thread.


19 Feb, 2015 2:39 PM

Arrrrrgh


19 Feb, 2015 2:28 PM

Horst Keller wrote:

In ABAP the official recommendation used to be to add a comment such as

ENDIF."Is the fish blue?

Used to be, but is it still?

See Comments.

Quote from "Arrangement in source Code" page:

"...

End of line comments are suitable for the following situations:

...

To indicate block ends (separate from indentations) in larger control structures

..."

and the "Good Example" is formatted as follows:

ENDIF. "item_ref IS BOUND AND...

ENDLOOP.

...

ENDMETHOD. "main

*----------------------------------------------------------*

ENDCLASS. "application
http://help.sap.com/abapdocu_740/en/index.htm?file=abencomments_guidl.htmhttp://scn.sap.com/people/adi.siekerhttp://scn.sap.com/people/adi.siekerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.keller


25/35



25

it does imply to use the endcomments.


19 Feb, 2015 1:14 PM



Used to be, but is it still?

See Comments.

Uwe Fetzerin response to Paul Hardyon page 25

19 Feb, 2015 12:12 PM

ADT always marks the current context of your writing position (IF/ELSE/ENDIF in this example):

Adi Siekerin response to Paul Hardyon page 25

19 Feb, 2015 12:03 PM

Paul Hardy wrote:



I think, if that is necessary to make the scope (method/function/form) readable then it's too complicated/long

and should be split up.

Paul Hardyin response to SAP ITR ENTWICKLUNGon page 2719 Feb, 2015 11:56 AM

I agree there is a big bonus with making code shorter (leaner)

In Java and so forth everyone is sed to the good old { }.

However for good or for bad ABAP programmers are used to things like ENDIF, and I wonder if } is more

readable e.g.
http://help.sap.com/abapdocu_740/en/index.htm?file=abencomments_guidl.htmhttp://scn.sap.com/people/paul.hardyhttp://scn.sap.com/people/paul.hardyhttp://scn.sap.com/people/adi.siekerhttp://scn.sap.com/people/adi.siekerhttp://scn.sap.com/servlet/JiveServlet/showImage/105-566342-648681/adt.PNGhttp://scn.sap.com/people/se38http://scn.sap.com/people/se38http://help.sap.com/abapdocu_740/en/index.htm?file=abencomments_guidl.htmhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.keller


26/35



26

is

ENDIF.

ENDCASE.

ENDMETHOD.

better than

}

}

}

When it comes to the readability stakes?

I presume in Eclipse when you hover over a "}" sign it tells you in a hover text the start of the code block the

sign is closing? In ABAP the official recommendation used to be to add a comment such as


Cheersy Cheers

Paul

Rdiger Plantikoin response to Adi Siekeron page 26

19 Feb, 2015 11:41 AM

My rule of thumb is: The implementation part of amethod should be visible completely on my screen, with

the signature part expanded => max. at about 30-40 lines of code per method, including blank lines andcomments.


19 Feb, 2015 9:08 AM

I also think that 150 executable statements is to much. I think it should be around 50-70.

Yes, that's the factor you can gain by using expression enabled ABAP .


19 Feb, 2015 9:05 AMHorst Keller wrote:

'xactly, see Procedure Volume

.
http://scn.sap.com/people/adi.siekerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/rdiger.plantiko2http://help.sap.com/abapdocu_740/en/index.htm?file=abenproc_volume_guidl.htmhttp://scn.sap.com/people/adi.siekerhttp://scn.sap.com/people/adi.siekerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/rdiger.plantiko2http://scn.sap.com/people/rdiger.plantiko2


27/35



27

In my opinion this is the number one thing that should be hammered into every developers head. I also think

that 150 executable statements is to much. I think it should be around 50-70.

Horst Kellerin response to Linkin Pereiraon page 27

19 Feb, 2015 8:51 AM

Well one argument would be with inline code you would not have 1000 lines of code

anyway

'xactly, see Procedure Volume .

Linkin Pereira

18 Feb, 2015 9:21 PM

Thanks for this Blog post Horst. I haven't started playing around with 7.4 yet but sure looks interesting.

One thing scares me though is this.

Rule

Only use inline declarations locally

Only make inline declarations in processing blocks that support . Use them as if they were local declarations in

the current statement block.

Details

If used correctly, inline declarations are an excellent way of making programs leaner and easier to understand.

------

The IF used correctly partin the Details.

--------

Don't you feel the code would be much difficult to maintain if the program is a 1000 lines code and some where

way up in the top there is an inline declared variable ( defined globally -- by mistake I may add) and you have

to debug this chunk of code to figure out where exactly is this variable defined.

With the usual declaration statement you know that the declaration is made with the TYPE statement.

-- Well one argument would be with inline code you would not have 1000 lines of code anyway.

Comments.

SAP ITR ENTWICKLUNGin response to Horst Kelleron page 29

18 Feb, 2015 4:30 PM

Maybe with a new syntax element for scoping blocks like {... scoping block } as we know it from Java, C++...

Additionally there could be a scoping version of other block building statements like
http://scn.sap.com/people/sapitr.entwicklunghttp://scn.sap.com/people/sapitr.entwicklunghttp://scn.sap.com/people/linkin.pereirahttp://scn.sap.com/people/linkin.pereirahttp://help.sap.com/abapdocu_740/en/index.htm?file=abenproc_volume_guidl.htmhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.keller


28/35



28

If x = Y { ... }

loop at lt_a into ls_a { ... }

case y { when a. ... }

replacing the end[something] with the block closing sign. This would at the same time make the code leanerand more readable.

Horst Kellerin response to Sayantika Bhattacharyaon page 28

21 Nov, 2014 5:58 PM

http://scn.sap.com/community/abap/blog/2014/10/08/abap-news-for-740-sp08--open-sql

Uwe Fetzerin response to Sayantika Bhattacharyaon page 28

21 Nov, 2014 3:58 PM

Inline declaration within open SQL comes in SP8.

Sayantika Bhattacharya

21 Nov, 2014 3:57 PMHi,

My system is on Release 7.40 SP006. Inline declaration is giving syntax error.

My Code:

REPORT zr_opensql_01_aggregation.

SELECT bp_id,

company_name,

so~currency_code,

SUM( so~gross_amount ) AS total_gross_amount

FROM snwd_so AS so

INNER JOIN snwd_bpa AS bpa

ON so~buyer_guid = bpa~node_key

INTO TABLE @DATA(lt_result)

GROUP BY bp_id, company_name, so~currency_code.

cl_demo_output=>display_data( value = lt_result ).

Syntax Error: The inline declaration "DATA(lt_result)" is not possible in this position.

Any inputs on why this is happening will help a lot.

Regards,
http://scn.sap.com/community/abap/blog/2014/10/08/abap-news-for-740-sp08--open-sqlhttp://scn.sap.com/people/sayantika.bhattacharyahttp://scn.sap.com/people/sayantika.bhattacharyahttp://scn.sap.com/people/se38http://scn.sap.com/people/se38http://scn.sap.com/community/abap/blog/2014/10/08/abap-news-for-740-sp08--open-sqlhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.keller


29/35



29

Sayantika.

Saurabh Kumbhare

24 Oct, 2014 2:51 PM

Thanks!!

Franz Seidl

24 Oct, 2014 10:00 AM

Good posting! Thank you!


14 Oct, 2014 11:05 AM

The backward compatibility trap. Building new features in old ABAP. There is no local context in old ABAP and

it seems to be impossible to enable it without breaking existing code.


14 Oct, 2014 10:41 AMHorst Keller wrote:

I know, I know, I know, ... sigh

sounds like that discussion as been had before.

But since it's not in there now and because people will start relying on it being the way it is now, it will never

happen.


14 Oct, 2014 9:13 AM

I know, I know, I know, ... sigh


14 Oct, 2014 9:11 AM

Horst Keller wrote:

Inline declarationsinfluenced theway we looked at those things and we tackled that as

follows

Programming Guideline for Inline Declarations

ideally the scope of inline declarations would be the block they were defined for.

That was the first question most colleagues asked me when I showed them inline declarations.
http://scn.sap.com/people/adi.siekerhttp://scn.sap.com/people/adi.siekerhttp://help.sap.com/abapdocu_740/en/index.htm?file=abendeclaration_inline_guidl.htmhttp://scn.sap.com/people/adi.siekerhttp://scn.sap.com/people/adi.siekerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/adi.siekerhttp://scn.sap.com/people/adi.siekerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/franz.seidl4http://scn.sap.com/people/franz.seidl4http://scn.sap.com/people/saurabhakumbharehttp://scn.sap.com/people/saurabhakumbhare


30/35



30

i.e.the following would cause a syntax error on the last line, stating that ls_struc is unknown:

LOOP AT lt_table into DATA(ls_struc).

"Do something with ls_struc.

ENDLOOP.

add 1 to ls_struc-counter.

Horst Kellerin response to Lokesh Balajeeon page 30

14 Oct, 2014 9:03 AM

Hi Lokesch,

But, when I try this, I get an error.

PARAMETERS: p_from TYPE /sapapo/locno.

DATA(g_from1) = DATA(g_from) = p_from.

Yes, inline declarations are forbidden in multiple assignments.

what is its effect on the global variables in Data declaration Includes

Global variables shouldn't be declared at all ...

But seriously:

Inline declarations influenced the way we looked at those things and we tackled that as follows

Programming Guideline for Inline Declarations

Horst

Lokesh Balajee

13 Oct, 2014 9:13 PM

Hello Horst,

I recently started exploring 7.4 features and its fascinating.

This works well


DATA(g_from) = p_from.

DATA(g_from1) = g_from.
http://help.sap.com/abapdocu_740/en/index.htm?file=abendeclaration_inline_guidl.htmhttp://scn.sap.com/people/balajlokhttp://scn.sap.com/people/balajlokhttp://help.sap.com/abapdocu_740/en/index.htm?file=abendeclaration_inline_guidl.htmhttp://help.sap.com/abapdocu_740/en/index.htm?file=abendeclaration_variables_guidl.htmhttp://help.sap.com/abapdocu_740/en/index.htm?file=ABAPMOVE_MULTIPLES.htmhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.keller


31/35



31

But, when I try this, I get an error.


DATA(g_from1) = DATA(g_from) = p_from.

Also one more question,

Though Inline declarations can be used always, what is its effect on the global variables in Data declarationIncludes?. The reason for this question is all the clients have coding standards and most of them will go for 1

Data declaration include and 1 Subroutine includes.

Lokesh

Christian Drummin response to Horst Kelleron page 31

4 Aug, 2014 10:33 PM

Hi Horst,

Thanks. That's what I was expecting. I'll have to use the explicit declaration in my case then.

Christian

Horst Kellerin response to Christian Drummon page 31

4 Aug, 2014 9:23 AM

Hi Christian,

Since you are using the dynamic ASSIGN COMPONENT, the field symbol declared inline has the generic type

ANY (how should the compiler know the type of the assigned component). A field symbol (or formal parameter)

that is not typed as an internal table cannot be used at operand positions for internal tables.

Your example would work with a static ASSIGN:

ASSIGN COMPONENT -items TO FIELD-SYMBOL().


If this is not possible, you have to declare and type the field symbol explicitly with TYPE ANY TABLE as you've

shown it. An inline declaration is not possible then.

Best,

Horst

Christian Drumm

2 Aug, 2014 5:26 PMHi Horst,

is there any way to use inline declaration together with field-symbols where the field-symbol is itself an itab?

What I'm trying to do is the following. I've got a structure example_order which has a component

example_order_items. Now I want to access this data using only field symbols and inline declarations. What I

tried is the following:
http://scn.sap.com/people/christian.drummhttp://scn.sap.com/people/christian.drummhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/christian.drummhttp://scn.sap.com/people/christian.drumm


32/35



32

ASSIGN COMPONENT 'ITEMS' OF STRUCTURE TO FIELD-SYMBOL().


This doesn't seem to work. At least I could't figure out how. If I use an explicitly declared field symbol instead

everything works fine:

FIELD-SYMBOLS TYPE ANY TABLE.

ASSIGN COMPONENT 'ITEMS' OF STRUCTURE TO


However, I'd like to use the inline declarations even in this case. Is this possible?

Best,

Christian

Adi Sieker

10 Jan, 2014 9:24 AM

Curently doing my first project on a 7.4 AS ABAP and inline declarations are just so nice. Been waiting for that

for ages.

Also method chaining and being able to directly access fields of a structure when calling functional methods

are just awesome.

Thank you ever so much, for the work in tht respect. Makes working with ABAP just so much more fun.

Shakeeluddin Khaja

17 Nov, 2013 7:50 AM

Useful Information. Thanks for sharing.

Regards.

Horst Kellerin response to Volodymyr Shcheglovon page 33

5 Oct, 2013 10:38 AM

Yes, see http://help.sap.com/abapdocu_740/en/abennews-740-operand_positions.htm.

Horst Kellerin response to Volodymyr Shcheglovon page 33

5 Oct, 2013 10:36 AM

lo_api->method( iv_bname = |{ lv_str }| ).

works, yes, but more "by chance" (string expression is handled like a string literal here).

Better to use the new CONV operator that wors explicitly and for any type.

why isn't that feature implemented for older constructions such as CALL FUNCTION
http://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/adi.siekerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://help.sap.com/abapdocu_740/en/abennews-740-operand_positions.htmhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/khaja.shakeeluddinhttp://scn.sap.com/people/khaja.shakeeluddinhttp://scn.sap.com/people/adi.siekerhttp://scn.sap.com/people/adi.sieker


33/35



33

http://help.sap.com/abapdocu_740/en/abennews-740-operand_positions.htm

But PERFORM is too outdated to be supported with the nice things ...

Volodymyr Shcheglovin response to Horst Kelleron page

4 Oct, 2013 11:15 PM

Horst Keller wrote:

Hi Custodio,

so let me rewrite my first example:

data(var) = rhs.

Where rhs is

any data object

a functional method call

a call of a built-in function

an arithmetic expression

a string expression

a bit expression

a constuctor expression

a table expression

Now it's your turn again

Dear Horst, will there be an ability to make a call like this:

CALL FUNCTION 'MY_FUNC'

EXPORTING

IV_PAR = lo_object->method( )

? This is really a demanding feature. Otherwise we need to declare a variable just to store a returning

parameter and then pass it to a function call. Moreover, this feature is fully supported in method calls.

Volodymyr Shcheglovin response to Rdiger Plantikoon page

4 Oct, 2013 11:09 PM

Rdiger Plantiko wrote:
http://scn.sap.com/people/volodymyrshcheglovhttp://scn.sap.com/people/volodymyrshcheglovhttp://scn.sap.com/people/volodymyrshcheglovhttp://scn.sap.com/people/volodymyrshcheglovhttp://help.sap.com/abapdocu_740/en/abennews-740-operand_positions.htm


34/35



34

Great news, Horst! Looking forward to 7.40 being shipped.

...

One example: Suppose I have a field in a STRING variable iv_name. Just because some

other developer didn't use the general type 'CSEQUENCE' for his API import parameter, I

have to add a data declaration for it and to move the STRING content to it before calling hisAPI:

data: lv_bname type BNAME.

lv_bname = iv_name. " (... supposing iv_name is a STRING field )

lo_api->method( exporting iv_bname = lv_bname ). " Doesn't accept the iv_name, bc. it's a

STRING.

Will there be a simplification for this kind of call too?

...

Regards,Rdiger

This example is slightly irrelevant because you can use string templates. Since ABAP version 7.02 one is able

to write the code such as:

data: lv_str type string value 'initial'.

lo_api->method( iv_bname = |{ lv_str }| ).

This is applicable only to methods. Unfortunately, you can't do the same for function or procedures calls.

By the way, question to Horst: why isn't that feature implemented for older constructions such as CALL

FUNCTION or PERFORM, or macro calls? Was it too difficult, or it was just assumed there was no demand for

such things?

As for Rdiger's example, the real problem is with other convertible types, say, P or N. For example, we have

a method's parameter is defined as IV_PAR(8) TYPE P DECIMALS 4, and an actual parameter, as LV_VAL(6)

TYPE P DECIMALS 2. It's obvious that this variable can be easily converted to the formal parameter's type but

right now you will get a syntax error trying to call this method as:

LO_OBJ->METHOD( IV_PAR = LV_VAL ).

So,

CONV #( lv_bname ) would be handy.

Rdiger Plantikoin response to Paul Hardyon page 35

4 Oct, 2013 12:03 PM
http://scn.sap.com/people/rdiger.plantiko2http://scn.sap.com/people/rdiger.plantiko2http://scn.sap.com/people/rdiger.plantiko2


35/35


[START DIGRESSION]

>It was better than the VIC20 even if that had much more memory

Disagree. The VIC20 had the better CPU: MOS Technology's 6502 was by far the best CPU available in the

market in those days - better then the 8080, and much better than the Z80 anyway. It's a pity that the x8...family won the race, although its concepts are worse. BTW - see here an impressive page of a 6502 fan,

emulating the currents inside the processor during execution! http://www.visual6502.org/JSSim/

[END DIGRESSION]


4 Oct, 2013 11:57 AM

http://en.wikipedia.org/wiki/List_comprehension

Paul Hardyin response to Horst Kelleron page

4 Oct, 2013 11:04 AMHooray!

In 7.02 in about 2011 you let ABAP have expressions ike A = ( B + C) a construct BASIC could do in 1981, so

if someone had jumped forward 30 years in a "Back to the Future" car they would have been comfortable with

the language.

Now in 2013 we have the good old FOR NEXT LET LOOPS which again look just like the ZX81 syntax when I

started to program when I was 14. I'm 45 now.

I'm not complaining - this is a good thing, I loved programming the ZX81 even if it only had 1K of memory. It

was better than the VIC20 even if that had much more memory the programming language onthe VIC20 had

lots of holes in it, and workarounds e.g. PEEK / POKE.

Programming languages must be like the fashion industry. Don't throw anything out of your wardrobe, in thirty

years it will be fashionable again.

Cheersy Cheers

Paul
http://scn.sap.com/people/paul.hardyhttp://scn.sap.com/people/paul.hardyhttp://en.wikipedia.org/wiki/List_comprehensionhttp://scn.sap.com/people/horst.kellerhttp://scn.sap.com/people/horst.kellerhttp://www.visual6502.org/JSSim/

Documents

Abap News for Release 740 Inline Declarations