For almost all platforms, the data should be static const. This would be enough, for most platforms. But since we don't want generic pointers that are checked at runtime to decide what processor instructions to use for access, the 8051 architecture would need an explicit code declaration both for the data and for the function return type.


Protection is only one piece of the puzzle. It's also a question of locality of reference. Having the code of a "get" function close to the actual declaration of the data means that a developer will get a better overview. You get a "programming by contract" concept where the function (or class method) can make an explicit promise.

The locality of reference also means that you could have special debug builds (for a PC, memory size doesn't matter much, but for embedded you still often have the chance to fit a chip variant with extra memory in one of your prototype boards) with some extra contracts checking.

So the function could have been extended with (in debug builds):

if (month < 1 || month > 12) trap_error();

And you could have a single breakpoint in the function trap_error() that would catch any error detected. Checking the call stack would tell where you came from, and why you trapped.

Or the debug build could have contained:

enum {
    ...
    ERR_MONTH_RANGE,
    ...
};
...

if (month < 1 || month > 12) report_error(ERR_MONTH_RANGE);

And a printout on a serial port could have printed "err:%un" to inform about the error, while potentially also printing the return address.


In most environments, the cost of extra function calls are quite cheap. Often not introducing much difference from doing the operations inline. And the encapsulation means that you often get code reuse by the function being called from more than one place. In many situations, you can even make the functions inline and have the compiler decide when it is better to inline the actual actions and when it's better to call a helper function.

This means that this type of programming can often work very well even for programs containing less than thousand lines of code. And it is easier to get reusable code blocks, since each function has very strict boundary for what it does and does not do.