IS SUPPLIED Considered Harmful
Contents
Well, at least in ABAP classes.
Default Parameter Values
Different programming languages have different implementations for default parameter values. That is, parameters that can be supplied but need not be.
Erlang
For example, Erlang does not have default parameter values at all: function timer:send_after/3
must always be called with three parameters.
|
|
However, since it is common for a process to queue a message to itself, it would be handy to have a shortcut for “send message to me after some time”. One option for this (in other languages) would be to use the current process as the default value of parameter Destination
. Erlang, which doesn’t have default parameter values, implements exactly the same using overloading:
|
|
Because timer:send_after/2
is not the same as timer:send_after/3
, no default parameters are necessary. Calling timer:send_after/2
becomes a call to timer:send_after/3
with the “default parameter value” in place.
A simpler example would go like this:
|
|
Swift
In Swift, parameters can have default values. Both positional and labeled parameters can have default values, but default values are a more natural fit for labeled parameters.
|
|
Scala
Scala has both default values and also another type of optional parameter, implicit
parameters.
|
|
JavaScript
In JavaScript, all parameters are (technically) optional and have undefined
as the default value.
|
|
Others
Java uses overloading, like Erlang.
Go doesn’t support overloading or default parameter values.
C# has default parameter values, like Swift and Scala.
Python has default parameter values, like Swift, Scala and C#.
Default and Optional Parameters in ABAP
ABAP, unlike many other languages, has both OPTIONAL
and DEFAULT
parameters.
|
|
OPTIONAL
and DEFAULT
are not really different things, OPTIONAL
just uses the type-specific INITIAL
value as the value of the parameter (empty string for character fields, 0 for integers and so forth).
Apart from the fact that there are two options for doing basically the same thing, this is pretty much like in other languages.
IS SUPPLIED…
What all the languages listed above – excluding ABAP – have in common, is that the methods cannot tell if they were called with an explicit value passed to the parameter where a default value is also an option. A parameter could obviously have a value that the method will then recognize as the default value, but even then someone could call the method by providing that default value to that parameter, and the method would be none the wiser.
|
|
In ABAP, it is possible to know if a value was passed to an optional parameter: enter IS SUPPLIED
.
|
|
Often the first reaction of programmers is “Cool!”, since IS SUPPLIED
can obviously distinguish between an initial value and a value that was not supplied at all. I would, however, argue that IS SUPPLIED
is more trouble than its worth and ABAPpers would do well by making do with only the features that other languages have.
…Considered Harmful
The trouble with IS SUPPLIED
arises when it is combined with classes. Consider the following:
|
|
Method set_foreign_trade_countries
allows caller to set country of origin, dispatch country or both, depending on how the method is invoked. This doesn’t look too bad and having the option to only partially update foreign trade details seems like a handy feature.
Now we subclass the delivery item.
|
|
This is more or less how we would implement the method in the subclass. However, in ABAP this naive implementation will not work.
|
|
Because the superclass method can detect how it is called, the exact form of the method call has to pass unchanged all the way through the class hierarchy or otherwise IS SUPPLIED
will not work as intended:
|
|
One optional parameter requires two method call combinations in every subclass, two optional parameters will require four and so forth. Not only is this a great place for hard-to-detect bugs, it will also add unnecessary hits to your where-used lists.
So using IS SUPPLIED
makes inheriting normal methods arduous, but it has an even worse effect on special methods like constructor
:
|
|
Trying the compile this will produce the following error:

constructor call cannot be conditional
In other words, it is impossible to cover all possible combinations of IS SUPPLIED
logic in constructors.
So IS SUPPLIED
can cause issues in methods, but it should be fine in function modules, right? Well, if you think back on how many BAPI function modules are basically just wrappers over other function modules, with minimal to no changes to the parameters, it would appear that the same troublesome pattern arises with function modules as well. There are even cases where IS SUPPLIED
doesn't work with function modules. So you’d probably be better off by giving up IS SUPPLIED
.
What about IS SUPPLIED
with CHANGING
parameters? You’d probably be better off by making the CHANGING
parameter mandatory if it is really required. If you just want to return something to the caller, use RETURNING
or EXPORTING
.
What about IS SUPPLIED
with EXPORTING
parameters? You’d probably be better off by using RETURNING
or making the EXPORTING
parameters VALUE()
s in order to uncouple the method implementation from how it was technically called.
Conclusion
IS SUPPLIED
introduces undesirable and unconventional coupling between the caller and method implementation. This coupling makes subclassing and other methods of wrapping existing functionality subject to strange bugs and cumbersome implementations. Other programming languages make do fine without such a programming language structure and ABAPpers would be wise to follow their example and avoid IS SUPPLIED
.