I'm wondering about the definition of a call-by-value EXPORTING argument of an ABAP method call.
The SAP Help Portal states that EXPORTING parameters can be defined call-by-value (and call by reference). It does not give a precise definition of how this parameter type is handled. Instead, it states
For precise details of the relevant ABAP statements, refer to the
corresponding keyword documentation in the ABAP Editor.
Now, the ABAP Keyword Documentation of the SAP editor does not mention pass-by-value for EXPORTING. (It does mention pass-by-value for IMPORTING and CHANGING).
I can guess the meaning of pass-by-value EXPORTING. But I want to read the definition. From FORM/PERFORM, I know that details can be subtle. Could you point me to an official description of this case?
I'm not sure in what way the details can be subtle even when using FORMs - but anyway, it's in the documentation:
There are two ways in which parameters can be passed: pass by
reference and pass by value. Pass by value is selected in the Function
Builder by selecting pass by value, and in the above syntax, differs
from pass by reference by the specification of VALUE( ).
In pass by reference, the formal parameter points directly to the actual parameter, so that changes to the formal parameters have an
immediate effect on the actual parameter.
In pass by value, when the function module is called, the formal parameter is created as a copy of the actual parameter (in IMPORTING
and CHANGING parameters), or initial (in EXPORTING parameters) in
the stack. In CHANGING and EXPORTING parameters, the formal
parameter is copied to the actual parameter when returning from the
function module.
Related
The ABAP documentation lists three kinds of modularization structures:
Methods. Problem: methods don't accept parameters.
Function modules. Problem: FMs belong to function groups and can be called from other programs. Apparently they are meant to be reused across the system.
Forms. Problem: are marked as "obsolete".
Is there a newer structure that replaces the obsolete FORM structure, that is:
Local to our program.
Accepts parameters.
Doesn't require ABAP Objects syntax ?
Methods. Problem: methods don't accept parameters.
I am not sure how you came to that conclusion, because methods support parameters very well. The only limitation compared to FORMs is that they don't support TABLES parameters to take a TABLE WITH HEADER LINE. But they support CHANGING parameters with internal tables, which covers any case where you don't actually need the header-line. And in the rare case that you are indeed forced to deal with a TABLE WITH HEADER LINE and the method actually needs the header-line (I pity you), you can pass the header-line as a separate parameter.
You declare a method with parameters like this:
CLASS lcl_main DEFINITION.
METHODS foo
IMPORTING iv_bar TYPE i
EXPORTING es_last_message TYPE bapiret2
CHANGING ct_all_messages TYPE bapiret2_t.
ENDCLASS.
And you call it either like that:
main->foo( IMPORTING iv_bar = 1
EXPORTING es_last_message = t_messages
CHANGING ct_all_messages = t_messages[] ).
or with the more classic syntax like that:
CALL METHOD main->foo
IMPORTING iv_bar = 1
EXPORTING es_last_message = t_messages
CHANGING ct_all_messages = t_messages[].
Function modules. Problem: FMs belong to function groups and can be called from other programs. Apparently they are meant to be reused across the system.
Yes, function modules are supposed to be global while FORM's are supposed to be local (supposed to: You can actually call a FORM in another program with PERFORM formname IN PROGRAM programname).
But classes can be local or global, depending on how you created them. A global class can be used by any program in the system. So function groups can be substituted by global classes in most cases.
The one use-case where function modules can not be substituted by methods of classes is for RFC-enabled function modules. RFC is the Remote Function Call protocol which allows external systems to execute a function module in another system via network. However, if you do need some other system to communicate with your SAP system, then you might want to consider to use webservices instead, which can be implemented with pure ABAP-OO. And they also offer much better interoperability with non-SAP systems because they don't require a proprietary protocol.
Is there a newer structure that replaces the obsolete FORM structure, that [...] Doesn't require ABAP Objects syntax ?
Here is where you got a problem. ABAP Objects syntax is the way we are supposed to program ABAP now. There is currently a pretty hard push to forget all the non-OO ways to write ABAP and fully embrace the ABAP-OO styles of writing code. With every new release, more classic syntax which can be substituted by ABAP-OO syntax gets declared obsolete.
However, so far SAP follows the philosophy of 100% backward compatibility. While they might try their best to compel people to not use certain obsolete language constructs (including adding scary-sounding warnings to the syntax check), they very rarely actually remove any language features. They hardly can, because they themselves got tons of legacy code which uses them and which would be far too expensive and risky to rewrite. The only case I can think of when they actually removed language features was when they introduced Unicode which made certain direct assignments between now incompatible types syntactically illegal.
You are having some wrong information there. Don't know what system version are you in, but this info could help you out:
Methods: They actually accept parameters (should be crazy if they wouldn't). In fact, they accept IMPORTING, EXPORTING, CHANGING and RETURNING parameters.
Forms: Indeed they are obsolete, but in my opinion there is no risk in using then, almost every standard component relies in programs made out of FORMS. FORMS are a core concept in ABAP programming. They are the "function" or "def" of many other languages. They accept USING, CHANGING and TABLES parameters.
If I setup optional parameters on a method in a VB.NET class, are the optional parameters supplied by the caller or the called method?
In C++, it is supplied by the called method.
In C#, it is supplied by the caller method.
Wondering how it worked in VB.NET.
Caller.
Another caveat C# folks might not know about is that the C# version of
optional parameters suffers from the same limitations of the VB
version (which, by the way, has been in VB since VS 2002). Namely,
the optional parameter value is a compiler trick, where the optional
parameter value is not compiled into the method called, but instead
into the caller.
Read more here: Caveats Of C# 4-0 optional parameters
By the caller. There is no universal value for "this argument was not specified" without drastically changing the method signature so the callee can't reliably tell that the argument was not supplied. It is the compiler that digs out the default value from the assembly metadata and uses it at the call site.
I am reviewing some code and I realized I don't remember the correct terminology for something. I believe if I had the following code
pnlOne.Visible = False
Would the "visible" part be considered a method, function, or what? I am learning VB alongside JavaScript, and in JS it would be a method. Is it the same for vb?
In VB.net, that is a "property". Properties in VB.net and C# as essentially glorified methods for getting and setting a value. (They actually compile down to something like get_Visible and set_Visible methods.)
pnlOne is an instance of a class and Visible is its property
Visible could be either ..
a Property; or
a Field (called "Member Variable" in VB)
.. depending on how it is declared. Both Properties and Fields are specializations of "Members"1. See Differences Between Properties and Variables in Visual Basic.
I suspect Visible is a Property in this case, and it will be for all standard Control types .. however, to verify this either way requires knowledge of the Type of the object named by pnlOne.
1
Methods (or "Sub/Function Procedures") are a different kind of Member and it is not appropriate to call either a Property or Field a "Function" or a "Method". (Note: various references inconsistently make a distinction between a Method and a Procedure; in VB.NET they an be thought of as synonyms.)
Nit: the correct term in JavaScript would be property; properties can evaluate to function-objects and can thus also can be considered methods when they do so - usually when this is used meaningfully. In any case, the code would have to be different (e.g. jsObj.set_Visible(true)) if a method was used.
How do I send parameters in smalltalk:
Pass-by-Value
Pass-by-Result
Pass-by-Value-result
Pass-by-References
Pass-by-Name
You can safely assume that all parameters in smalltalk are passed by reference.
There's only one exception for immediate object (smallintegers) which are passed by value,
but its an implementation detail (different implementations could have different kinds of immediate object classes).
AFAK, Smallscript Smalltalk uses pass-by-value as default unless you use the & sign for pass by reference just like C++, there is more information on this here.
But traditionally Smalltalk uses pass by reference as mentioned here and here.
In VB.NET, which is better to use: function overloading or default parameters?
if the parameters are optional (i.e. the overloads are a subset of the parameters that the full procedure signature accepts) then default or optional parameters would make more sense.
If the overload is allowing a different type for the parameter or is a semantically different parameter that will be interpreted differently by the routine then overloads would make more sense.
Is the code going to be used by other languages? If so, that swings the balance towards overloads while still bearing Hamish's answer in mind. In particular, C# doesn't support optional parameters - yet...
Admittedly this wouldn't actually prevent someone using your code from C#, it just might be a pain for them.
If there are a lot of parameters and they logically represent something, you might want to consider encapsulating them together, in the same way that Process works with ProcessStartInfo. That's particularly nice from C# due to object initializers.
If this is for construction, you might also consider the builder pattern as a variant of this. For instance, in Protocol Buffers I can do something like:
Person jon = new Person.Builder { Name="Jon", Age=32,
Spouse="Holly", Kids=3 }.Build();
which ends up being very readable while still creating a person in one go (in one expression, and without having to mutate the person itself - indeed the message type is immutable; it's only the builder which isn't).
FYI
If you want to add a parameter to a function or method that is called from other assemblies, then:
You can overload by making an additional function with the extra parameter.
Or you can add an optional parameter, BUT: You have to recompile all of the assemblies that call this function, even if they don't need to use the new optional parameter! This is not usually what people expect (expecially those used to how VB6 works). Basically, you can't slip in a new optional parameter to a function and expect it to be totally backwards compatible. Also, as I understand it, if you change what the default value is, you need to rebuild all calling assemblies for the change to work.