Simulating object behavior

Kerbal Operating System does not support OOP, nor does FALL implement an OOP layer on top of KOS. What it does however is make use of associative arrays in the form of lexicons to mimic object like behavior. Because KOS supports function delegates, lexicons can be utilised as a collection of functions accessed by keys. On top of that each function delegate “remembers” its local scope.

Table of contents:

• Why?
• How?
• Drawbacks

Why?

This approach makes the project well organised, modular and easy to use without having to worry about potential namespace flooding and wondering “is this function in this file or that file?”. Since each structure defined by FALL is independent through means of aggregation, it’s possible to expand the module more freely and allow users to define their own components.

How?

Take a look at this example written for KOS:

// defining person "class"
function person {
  parameter job is "Unemployed".

  function getJob {
      // returns current job
      return job.
  }

  function setJob {
      // changes job
      parameter newJob.
      set job to newJob.
  }

  function eat {
      print job + ": NOM NOM NOM!".
  }

  // returns functions
  return lexicon(
      "getJob", getJob@,
      "setJob", setJob@,
      "eat", eat@
      ).
}

We’ve defined a function, that returns lexicon of function delegates! Let’s test it:

local firstPerson is person().  // creating new person object
local secondPerson is person(). // creating new person object

print firstPerson["getJob"]().  // prints "Unemployed"
print secondPerson["getJob"](). // prints "Unemployed"

// changing the first persons job
firstPerson["setJob"]("Programmer")

print firstPerson["getJob"]().  // prints "Programmer"
print secondPerson["getJob"](). // prints "Unemployed"

// the first person is hungry
firstPerson["eat"]().           // prints "Programmer: NOM NOM NOM!"  

We’ve proven that the state of each person is:

• independent
• can be mutated only through available functions

These results tell us that we’ve successfully simulated the core characteristics of objects in OOP:

• Identity
• behavior
• State
• Encapsulation

Almost all of FALL structures are defined with this approach.

Drawbacks

There are drawbacks to every approach we can think of. In the case of FALL the very first thing that comes to mind is that this paradigm is probably not what creators of the KOS had in mind when designing the language.

Another thing that I realise is that KOS is a great educational tool for non-programmers. I suspect that KOS was the very first encounter with programming for many people. It means that OOP vocabulary and philosophy may be outlandish to these individuals, which hurts the accessibility aspect of this module.

Because FALL currently doesn’t implement a full blown OOP layer, this solution lacks type checking and inheritance.