Going All The Way With Control Tables

Version: 1.0

NOTE: This is only a brainstorming document. It is not meant to finalize any syntax or approach.

The idea is to put everything related to a class and it's subclasses into a control table. This differs from our prior approach in that:

  1. Entire methods are stored in the cells, not just codes or expressions. Our table browser should provide a way to not show the entire code of large methods unless we explicitly ask it too, such as double-clicking on a cell. (It is similar to the way some Xbase browsers would display memo field windows if you double-clicked or pressed certain keys. However, perhaps a portion should still be displayed before full opening.)

  2. The language would allow easy conversion between the table version and a code version. They are considered interchangeable. The code version is shown near the bottom.

  3. There are a few rows dedicated to a "parent" class (shown in light blue). The parent class basically tells how to process the the subclass information and/or supply defaults. (These parent rows are optional.) In our prior control table examples, there was no formal place for these actions, other than manual code. Note that we are providing only explicit handling of two levels of inheritance: one parent and direct children.

Example "Animals" Table
Subclass Sound FoodType Domestic Train
define default "I have no sound"     % notrain()
define evaluator playsound(@)      
define assignor     % if not in(@,"Y","N")
{raiseErr()} else {return @}
Wolf howl carn. N  
Rat % rodentsound() misc. N  
Cow moo herb. Y  
Dog ruf ruf misc. Y % while not trained{try(); reward()}

The blue shaded rows represent "definition" subclasses. In our code version they are combined into a single class definition.

The "@" symbol represents the value looked up from the relevant subclass. The percent symbol represents that a method/function is to supply the value of the attribute or method instead of a value. Notice how the Rat sound is calculated instead of hardwired into the table. The distinction between a method and an attribute are blurred. (These symbols are only preliminary suggestions.)

The "evaluator" row triggers whenever the corresponding method is called:

Here, "playsound()" is executed in this case with the cow's sound string passed to it. However, if we did:
   x = Cow.sound
then only "moo" is returned. If we did:
   x = Rat.sound
then rodentSound() would be executed in order to generate the value. If we requested:
then both rodentSound() and playSound() would be executed. It would be roughly equivalent to:

The "assignor" row evaluates whenever an assignment is made to a subclass. For example, if:

   Dog.domestic = "Z"
is attempted, then an error is triggered because the corresponding assignor cell performs a validation.

Now for the code version:

  class Animals {
    method Sound {
      temp = @
      if empty(temp) {  // implement default
        temp = "I have no sound"
      return playsound(temp)
    method required FoodType {
      return @
    method required Domestic {
      return @
    method assignor Domestic {
      if not in(@,"Y","N")
      {raiseErr()} else {return @} 
    method Train {
      if empty(@) {
        return notrain()
      } else {
        return @
  } // end class

  subclass Wolf extends animals {
    method sound {return "howl"}
    method foodtype {return "carn."}
    method domestic {return "N" }
  subclass Rat extends animals {
    method sound {return rodentsound() }
    method foodtype {return "misc." }
    method domestic {return "N" }
  subclass Cow extends animals {
    method sound {return "moo"}
    method foodtype {return "herb."}
    method domestic {return "Y"}
  subclass Dog extends animals {
    method sound {return "ruf ruf"}
    method foodtype {return "misc."}
    method domestic {return "Y"}
    method train {return while not trained{try(); reward()} }

Control Tables | Table-Oriented Programming